Oracle 9i Fundamentals I Exam Cram™ 2 (Exam 1Z0-031)

Team LiB
Next Section
Book Cover
• | Table of Contents
• | Index
• | Examples
Oracle 9i Fundamentals I Exam Cram™ 2 (Exam 1Z0-031)
By April Wells
Publisher | : Que
Pub Date | : December 03, 2004
ISBN | : 0-7897-3265-3
Pages | : 544

Whether you're studying for the Oracle 9i Fundamentals I exam or just need to take the New Features update exam, Oracle 9i Funamentals I Exam Cram 2 can help you get certified. This efficient guide follows the exam objectives clearly and concisely. New Features materials are also included in the book, as well as a full-customizable practice test engine on CD. Oracle 9i Fundamentals I Exam Cram 2 is your smartest way to get certified.

Team LiB
Next Section


Table of Contents

Team LiB
Book Cover
• | Table of Contents
• | Index
• | Examples
Oracle 9i Fundamentals I Exam Cram™ 2 (Exam 1Z0-031)
By April Wells
Publisher | : Que
Pub Date | : December 03, 2004
ISBN | : 0-7897-3265-3
Pages | : 544

Copyright
Oracle 9i Cram Sheet
 | THE ITERATIVE SYSTEM DEVELOPMENT CYCLE
 | BASIC TERMINOLOGY
 | THE SELECT STATEMENT
 | JOINING TABLES
 | SPECIALIZED QUERIES
 | OPERATORS
 | CONDITIONS
 | PSEUDOCOLUMNS
 | EXPRESSIONS
 | FUNCTIONS
 | CHANGING DATA (DML)
A Note from Series Editor Ed Tittel
About the Author
About the Technical Editors
Acknowledgements
We Want to Hear from You!
Introduction
 | How to Prepare for an Exam
 | Exam Format
 | Testing Situation
 | Using the Book
Self-Assessment
 | In the Real World
 | The Ideal Candidate
 | Put Yourself to the Test
 | Assessing Your Readiness for the Exam
 | Onward Through the Fog
Chapter 1. Oracle Architecture Components
 | Database Versus Instance
 | Datafiles
 | Memory Structures
 | Shared SQL Area
 | Program Global Areas (PGA) Overview
 | Process Architecture
 | Background Processes
 | Connecting to an Instance
 | Exam Prep Questions
 | Need to Know More?
Chapter 2. Getting Started with the Oracle Server
 | Administrative Tools
 | Oracle Universal Installer (OUI)
 | Oracle Database Configuration Assistant (DBCA)
 | Optimal Flexible Architecture (OFA)
 | Password File Authentication
 | DBA Tools
 | Exam Prep Questions
Chapter 3. Creating a Database
 | Prerequisites for Database Creation
 | Planning Database File Locations
 | Creating the Database
 | Oracle Database Configuration Assistant
 | Create a Database Manually
 | What to Do If Database Creation Fails
 | Exam Prep Questions
 | Need to Know More?
Chapter 4. Managing an Instance
 | Initialization Parameter Files
 | Oracle Managed File (OMF) System
 | Database Startup
 | Working with the STARTUP Command
 | Shutting Down the Database
 | Managing the Instance by Monitoring the Diagnostic Files
 | Exam Prep Questions
 | Need to Know More?
Chapter 5. Data Dictionary Content and Usage
 | Oracle's Data Dictionary
 | How the Data Dictionary Is Used
 | Accessing Data Dictionary and Dynamic Performance Views
 | Creating the Data Dictionary
 | Common Views and Their Uses
 | Exam Prep Questions
 | Need to Know More?
Chapter 6. Storage Structure and Relationships
 | Segments
 | Extents
 | Database Data Blocks
 | Block Utilization Parameter
 | Storage Structure Information in the Data Dictionary
 | Exam Prep Questions
 | Need to Know More?
Chapter 7. Globalization Support
 | Globalization Support
 | Character Sets and Encoding Schemes
 | Database Character Set
 | National Character Set
 | Language-Dependent Behavior Specification
 | Setting Environment Variables
 | Linguistic Sorting
 | Language-Dependent Application Behavior
 | Globalization Support Information in the Data Dictionary
 | Globalization Support Utilities
 | Exam Prep Questions
Chapter 8. Maintaining Control Files
 | What Are Control Files?
 | Multiplexing Control Files
 | The CREATE CONTROLFILE Command
 | Dropping Control Files
 | Backing Up the Control File
 | Obtaining Control File Information
 | Control File-Related Parameters
 | Managing the Control File with OMF
 | Exam Prep Questions
Chapter 9. Maintaining Redo Log Files
 | Purpose of Online Redo Log Files
 | Structure of Online Redo Log Files
 | Control Log Switches and Checkpoints
 | Multiplexing and Maintaining Online Redo Log Files
 | Using OEM to Maintain Redo Log Groups and Members
 | Managing Redo Log Files with OMF
 | Data Dictionary Redo Information
 | Archived Redo Log Files
 | Exam Prep Questions
Chapter 10. Managing Tablespaces and Data Files
 | Logical Structure of the Database
 | Types of Tablespaces
 | Creating Tablespaces
 | Dropping Tablespaces
 | Space Management in Tablespaces
 | Changing the Size of the Tablespace
 | Manipulating Tablespaces and Data Files with OEM
 | Implementing Oracle Managed Files (OMF)
 | Data Dictionary Tablespace and Data File Information
 | Exam Prep Questions
 | Need to Know More?
Chapter 11. Managing Undo Data
 | Logical Structure of Undo Segments in the Database
 | Purpose of Undo Data
 | Types of Undo Data
 | Implementing Automatic Undo Management
 | Data Dictionary Information on Undo
 | Exam Prep Questions
Chapter 12. Managing Tables
 | Methods of Storing Data
 | Oracle Data Types
 | Structure of a Row
 | Creating Regular and Temporary Tables
 | External Tables
 | Managing Storage Structures
 | Regular Table Operations
 | Column Operations
 | Data Dictionary Information on Tables
 | Exam Prep Questions
Chapter 13. Managing Indexes
 | Different Types of Indexes and Their Uses
 | Creating Indexes
 | Changing Storage Parameters for Indexes
 | Reorganizing Indexes
 | Index Information in the Data Dictionary
 | Exam Prep Questions
Chapter 14. Maintaining Data Integrity
 | Defining Data Integrity
 | Implementing Data Integrity Constraints
 | Maintaining Integrity Constraints
 | Constraint Information in the Data Dictionary
 | Exam Prep Questions
Chapter 15. Managing Users
 | Creating New Users
 | Altering Users
 | Dropping Users
 | User Information in the Data Dictionary
 | Exam Prep Questions
Chapter 16. Managing Password Security and Resources
 | Manage Passwords Using Profiles
 | Administering Profiles
 | Controlling Resources Using Profiles
 | Managing Resource Plans and Consumer Groups
 | Data Dictionary Information About Profiles, Password Management, and Resources
 | Exam Prep Questions
Chapter 17. Managing Privileges
 | System Privileges
 | Object Privileges
 | Auditing Capabilities
 | Data Dictionary Information
 | Exam Prep Questions
Chapter 18. Managing Roles
 | Creating and Modifying Roles
 | Granting Roles
 | Controlling Availability of Roles
 | Removing Roles
 | Using Predefined Roles
 | Role Creation Guidelines
 | Role Information in the Data Dictionary
 | Exam Prep Questions
Chapter 19. Practice Exam 1
Chapter 20. Exam 1 Answers
Chapter 21. Practice Exam 2
Chapter 22. Exam 2 Answers
Appendix A. CD Contents and Installation Instructions
 | Multiple Test Modes
 | Question Types
 | Random Questions and Order of Answers
 | Detailed Explanations of Correct and Incorrect Answers
 | Attention to Exam Objectives
 | Installing the CD
 | Technical Support
Glossary
Appendix C. Need to Know More?
 | Chapter 1: Oracle Architectural Components
 | Chapter 2: Getting Started with the Oracle Server
 | Chapter 3: Creating a Database
 | Chapter 4: Managing an Instance
 | Chapter 5: Data Dictionary Content and Usage
 | Chapter 6: Storage Structure and Relationships
 | Chapter 7: Globalization Support
 | Chapter 8: Maintaining Control Files
 | Chapter 9: Maintaining Redo Log Files
 | Chapter 10: Managing Tablespaces and Data Files
 | Chapter 11: Managing Undo Data
 | Chapter 12: Managing Tables
 | Chapter 13: Managing Indexes
 | Chapter 14: Maintaining Data Integrity
 | Chapter 15: Managing Users
 | Chapter 16: Managing Password Security and Resources
 | Chapter 17: Managing Privileges
 | Chapter 18: Managing Roles
Index

Team LiB


Copyright

Copyright © 2005 by Que Publishing

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

Library of Congress Catalog Card Number: 2004108927

Printed in the United States of America

First Printing: October 2004

07 06 05 04 4 3 2 1

Trademarks

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Que Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the CD or programs accompanying it.

Bulk Sales

Que Publishing offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact

U.S. Corporate and Government Sales
1-800-382-3419
corpsales@pearsontechgroup.com

For sales outside the U.S., please contact

International Sales
international@pearsoned.com

Credits

Publisher

Paul Boger

Executive Editor

Jeff Riley

Acquisitions Editor

Carol Ackerman

Development Editor

Gus Miklos

Managing Editor

Charlotte Clapp

Project Editor

Andy Beaster

Copy Editor

Geneil Breeze

Indexer

Rebecca Salerno

Proofreader

Katherin Bidwell

Technical Editors

Rachel Carmichel

Kimberly Floss

Publishing Coordinator

Pamalee Nelson

Multimedia Developer

Dan Scherf

Interior Designer

Gary Adair

Cover Designer

Anne Jones

Page Layout

Michelle Mitchell

Dedication

As always, I dedicate this book to Larry, Adam, and Amandya, my family, who were always there, always supportive, and always patient even when I wasn't. You have been understanding when I have been short tempered and when I wrote even when everyone else was having fun. Having you there has meant everything to me.


Oracle 9i Cram Sheet

This Cram Sheet contains last-minute reminders you can review briefly before the exam starts. You cannot take this cram sheet with you into the exam!


THE ITERATIVE SYSTEM DEVELOPMENT CYCLE

  1. Strategy and Analysis Analyze user requirements and produce system specification.

  2. Design Technical design documentation, a product of Strategy and Analysis.

  3. Build and Document Convert Design into executable software code and data structures.

  4. Transition User acceptance testing and bug removal.

  5. Production Applications release and support passed to production support.


BASIC TERMINOLOGY

  • SQL Structured Query Language.

  • DML Data Manipulation Language (ROLLBACK allowed).

  • DDL Data Definition Language (ROLLBACK not allowed).


THE SELECT STATEMENT

The SELECT statement is used to retrieve data from a database. A SELECT statement is also known as a query because it queries a database.

  • Simple SELECT:

    SELECT *|<column> [AS <name>|"name"][,...] FROM [<schema>.]<table>;

  • Add an alias:

    SELECT [<alias>.]*|[<alias>.]<column> [,...]
FROM [<schema>.]<table> [<alias>];

  • Retrieve unique (DISTINCT) items:

    SELECT DISTINCT|UNIQUE [(]<column>[,...][)] FROM [<schema>.]<table>;

The WHERE Clause

The optional WHERE clause is used to filter rows in a query, an UPDATE command, or a DELETE command.

  • Simple comparison:

    SELECT * FROM [<schema>.]<table>
[WHERE [<schema>.][[<table>.]|[<alias>.]]<column>
    <comparison>[...]<column>];

  • Conjunctive comparison using logical conditions:

    SELECT * FROM [<schema>.]<table>
[WHERE [<schema>.][[<table>.]|[<alias>.]]<column>
    <comparison>[...]<column>
AND [NOT]| OR [NOT] [...]<column> <comparison>[...]<column>
AND [NOT]| OR [NOT] ... ];

  • The UPDATE and DELETE commands:

    UPDATE [<schema>.]<table> SET ...
[WHERE [<schema>.][[<table>.]|[<alias>.]]<column>
    <comparison>[...]<column> ...];

DELETE FROM [<schema>.]<table>
[WHERE [<schema>.][[<table>.]|[<alias>.]]<column>
    <comparison>[...]<column> ...];

The ORDER BY Clause

The optional ORDER BY clause is used to sort rows returned by a query, and it can also be a part of the OVER clause for analysis.

  • Simple sorting:

    SELECT * FROM [<schema>.]<table> [WHERE]
[ORDER BY {[<alias>.]<column>|<position>}[,...]];

  • Ascending (the default) and descending sorts:

    SELECT * FROM [<schema>.]<table> [WHERE]
[ORDER BY {[<alias>.]<column> [ASC|DESC]
    |<position> [ASC|DESC]}[,...[ASC|DESC]]];

  • Sorting NULL values (by default returned last):

    SELECT * FROM [<schema>.]<table> [WHERE]
[ORDER BY {[<alias>.]<column> [ASC|DESC][NULLS {FIRST|LAST}]
   |<position> [ASC|DESC][NULLS {FIRST|LAST}]}[,...[ASC|DESC]]];

  • The OVER clause:

    SELECT {<column> [AS OVER() [ORDER BY]...]}[,...]
FROM <table> [WHERE][ORDER BY];

The GROUP BY Clause

The optional GROUP BY clause is used to summarize, aggregate, and analyze groupings returned from queries. Any SELECT list elements not included in aggregation functions must be included in the GROUP BY list of elements. This includes both columns and expressions. At least one element of the SELECT list of elements must be subjected to an aggregation function.

  • Simple GROUP BY:

    SELECT * FROM [<schema>.]<table> [WHERE]
[GROUP BY [<alias>.]<column>[,...]][ORDER BY];

  • Filtering groups with the optional HAVING clause (similar syntax to that of the WHERE clause):

    SELECT * FROM [<schema>.]<table> [WHERE]
[GROUP BY ... [HAVING <column> <comparison> <column> [,...]]]
[ORDER BY];

  • Extending the GROUP BY clause with OLAP functionality using the ROLLBUP, CUBE, and GROUPING SETS clauses:

    SELECT * FROM [<schema>.]<table> [WHERE]
[GROUP BY ... [HAVING ...]
[ROLLUP(<column>,[...])|CUBE(<column> [,...])
    |GROUPING SETS((<group>)[,...])][ORDER BY];


JOINING TABLES

Tables can be joined such that results from one or more tables appear in the same query result. Joins can be an outer join, a Cartesian Product (a cross join), a table joined to itself (a self join), or a semi join.

  • Oracle join syntax is placed into the WHERE clause using the (+) operator (outer join operator), determining the side of an outer join deficient in information:

    SELECT * FROM <table>
[WHERE <column> <comparison> <column> [(+)]]
    |[WHERE <column>[(+)] <comparison> <column>]
AND [NOT]| OR [NOT] ... ][GROUP BY][ORDER BY];

  • ANSI join syntax is placed into the FROM clause using the JOIN keyword:

    SELECT * FROM <table> [JOIN <table> [JOIN <table> ...]]
[WHERE][GROUP BY][ORDER BY];

  • ANSI join syntax allows the CROSS JOIN clause to create a Cartesian Product between two tables:

    SELECT *
FROM <table> [[CROSS] JOIN <table> [[CROSS] JOIN <table> ...]]
[WHERE][GROUP BY][ORDER BY];

  • ANSI join syntax can use the NATURAL keyword to create both inner and outer joins, joining tables on columns with the same name in the different tables:

    SELECT *
FROM <table> [[NATURAL] JOIN <table> [[NATURAL] JOIN <table> ...]]
[WHERE][GROUP BY][ORDER BY];

  • ANSI join syntax can utilize the USING clause to specify exact column names to join on, avoiding joins on same-named columns with different meanings:

    SELECT *
FROM <table> [JOIN <table> USING(<column>[,...])
    [JOIN <table> ...] USING(<column>[,...])]
[WHERE][GROUP BY][ORDER BY];

  • ANSI join syntax can utilize the ON clause to specify exact column names to join on, specifically when different-named columns are required in the join, usually requiring a table or alias reference:

    SELECT *
FROM <table> a [JOIN <table> b
    ON (a.<column>=b.<column> [AND [NOT]| OR [NOT] ... ] [,...])
        [JOIN <table> c] ON(...)]
[WHERE][GROUP BY][ORDER BY];


SPECIALIZED QUERIES

  • Subqueries can return single values (scalar), multiple columns or multiple rows, or both. Subqueries can be used in a SELECT clause elements list, the FROM clause, the WHERE clause, the ORDER BY clause, an INSERT statement VALUES clause, an UPDATE statement set clause, or a CASE statement expression. Also tables and views can be created using subqueries.

  • The WITH clause allows prepared execution of subquery results. Results can then be utilized by the primary calling query:

    WITH query1 AS (subquery), query2 AS (subquery)
SELECT * FROM query1 JOIN query2 JOIN query3;

  • Hierarchical queries allow hierarchical representations of hierarchical data. The hierarchy can be accessed from the root node or a starting point within the hierarchy (the START WITH clause). The CONNECT BY clause allows linking between a column in the current row and another value in a parent (the PRIOR operator) row:

    SELECT <column>, LEVEL FROM <table> START WITH <condition>
CONNECT BY <current_row> <parent_column>
    = PRIOR <parent_row>
<current_column>;

  • Flashback queries allow a query flashback to a specific point in time, based on a timestamp or an SCN:

    SELECT * FROM ... AS OF {TIMESTAMP|SCN};

  • A Top-N query can be used to retrieve a small number of rows from a large row set.

    SELECT * FROM (SELECT * FROM <table> ORDER BY ...)
WHERE ROWNUM < n;


OPERATORS

  • String concatenation operator || concatenates two strings together; for example, 'My name is'||' '||'Joe' returns the string My name is Joe.

  • Set operators Set operators allow concatenation of results from two queries. UNION ALL returns all rows including duplicates, UNION returns all unique rows, INTERSECT returns all rows common to both queries, and MINUS returns all rows in one and not the other query.

  • Hierarchical query operator The PRIOR operator placed with the CONNECT BY clause links the current row with a parent row.


CONDITIONS

  • Comparison conditions:

    • Equi (=), Anti (!=, <>, ^=), and Range (<, >, =<, >=).

    • [NOT] LIKEPattern matching.

    • [NOT] INSet membership between expressions.

    • [NOT] EXISTSSet membership producing a Boolean result.

    • [NOT] BETWEENRange search between two values, inclusive of end points.

    • ANY, SOME, and ALLSet membership conditions.

      • IS [NOT] NULLNULL value testcondition.

  • Logical conditions, in order of precedence:

    • NOTAn expression being false yields true.

    • ANDTwo expressions being true yield true.

    • OROne of two expressions being true yields true.


PSEUDOCOLUMNS

  • ROWID Relative row pointer.

  • ROWNUM A sequence number for rows returned by a query as the rows are returned.

  • <sequence>.CURRVAL and <sequence>.NEXTVAL The current and next values for a sequence.

  • LEVEL Returns the level of a row in a hierarchical query.


EXPRESSIONS

  • CURSOR expression An embedded or inline cursor inside a calling SQL statement:

    SELECT ...,CURSOR(<subquery>),... FROM ...;

  • CASE expression An embedded or inline CASE statement inside a SQL statement as a simple CASE statement:

    SELECT ... CASE expression WHEN condition THEN ...
    WHEN condition THEN ... ELSE ... END FROM table;

    Or a search CASE statement:

    SELECT ... CASE WHEN <condition> THEN ...
    WHEN <condition> THEN ... ELSE ... END FROM table;


FUNCTIONS

Functions can be used in a SELECT statement item selection list, WHERE and ORDER BY clauses, GROUP BY and HAVING clauses, CONNECT BY and START WITH clauses in hierarchical queries, plus INSERT VALUES and UPDATE SET clauses.

Single Row Functions

Execute an operation on each row of a query:

  • Strings:

    • INSTR(<string>,<substring>[,<position>[,occurrence>]])

    • LENGTH(<string>)

    • INITCAP(<string>)

    • LOWER(<string>)

    • UPPER(<string>)

    • LPAD(<string>,<n>[,<replace>)

    • RPAD LPAD(<string>,<n>[,<replace>)

    • LTRIM(<string>,<string>)

    • RTRIM(<string>,<string>)

    • trIM([[LEADING|TRAILING|BOTH] <character> FROM] <string>)

    • SUBSTR(<string>[,[-]<position> [,<n>]])

    • REPLACE(<string>,<search> [,<replace>])

  • Numbers:

    • ABS(<n>)

    • POWER(<n>,<exponent>)

    • SQRT(<n>)

    • CEIL(<n>)

    • FLOOR(<n>)

    • ROUND(<n>,<decimal places>)

    • TRUNC(<n>,<decimal places>)

    • MOD(<numerator>,<denominator>)

    • SIGN(<n>)

  • Datetime:

    • SYSDATE

    • CURRENT_DATE

    • CURRENT_TIMESTAMP(<precision>)

    • LOCALTIMESTAMP(<precision>)

    • NEXT_DAY(<date>,<weekday>)

    • LAST_DAY(<date>)

    • ADD_MONTHS(<date>,<months>)

    • MONTHS_BETWEEN(<date>,<date>)

    • EXTRACT(<format> FROM {<date>|<timestamp>)

    • ROUND(<date>[,<format>])

    • trUNC(<date>[,<format>])

  • Datatype conversions:

    • TO_NUMBER(<n>[,<format>])

    • TO_[N]CHAR(<string>[,<format>])

    • TO_DATE(<string>,<format>)

    • TO_[N]CHAR(<datetime>,<format>)

  • Miscellaneous:

    • DECODE(<expression>,<search>, <replace>

      [,<search>,<replace>...],<default>)

      • NULLIF(<expression>,<expression>)

      • NVL(<expression>,<expression>)

      • NVL2(<expression>,<expression>,<expression>)

      • USER

      • USERENV(<parameter>)

      • GREATEST(<expression>[,<expression>...])

      • LEAST(<expression>[,<expression>...])

Aggregate Functions

Summarize repeating groups in a row set into distinct groups, creating values such as sums or averages:

  • Simple summaries:

    • COUNT(*|[DISTINCT|ALL] <expression>)

    • AVG([DISTINCT|ALL] <expression>)

    • MIN([DISTINCT|ALL] <expression>)

    • MAX([DISTINCT|ALL] <expression>)

    • SUM([DISTINCT|ALL] <expression>)

  • Simple statistics:

    • STDDEV([DISTINCT|ALL] <expression>)

    • VARIANCE([DISTINCT|ALL] <expression>)

    • CORR(<expression>,<expression>)

    • STDDEV_{POP|SAMP}(<expression>)

    • VAR_{POP|SAMP}(<expression>)


CHANGING DATA (DML)

INSERT INTO <table>[(<column_list>)]
    {VALUES(<expression_list>)|<subquery>};

  • Conditional multiple table INSERT:

    INSERT WHEN <condition> THEN INTO <table1>
    WHEN <condition> THEN INTO <table2>
    ...
    WHEN <condition> THEN INTO <tablen>
SELECT ... FROM ...;

  • Non-conditional multiple table INSERT:

    INSERT ALL INTO <table1>(<column_list>) VALUES(<expression_list>)
    INTO <table2>(<column_list>) VALUES(<expression_list>)
    ...
    INTO <tablen>(<column_list>) VALUES(<expression_list>)
SELECT ... FROM ...;

  • UPDATE:

    UPDATE <table> SET <column>=<expression>|(<subquery>) [,...] [WHERE];

  • DELETE:

    DELETE FROM <table> [WHERE];

  • MERGE:

    MERGE INTO <target_table> t USING <source_table> s
    ON(s.<column>=t.<column> [AND|OR ...]
WHEN MATCHED THEN UPDATE SET t.<column>=s.<column> ...
WHEN NOT MATCHED THEN INSERT VALUES(<column list> ...);

    • TRansactions are controlled by COMMIT (permanently store pending changes), ROLLBACK (undo pending changes), and SAVEPOINT (partial rollback to a SAVEPOINT label). The LOCK TABLE command can be used to temporarily lock tables. The SET TRANSACTION command can be used to control transaction behavior in general:

      SET TRANSACTION {READ ONLY|READ WRITE
    |ISOLATION LEVEL{SERIALIZABLE|READ COMMITTED}
    |USE ROLLBACK SEGMENT} [NAME '<transaction>'];


A Note from Series Editor Ed Tittel

Que Certification • 800 East 96th Street • Indianapolis, Indiana 46240

You know better than to trust your certification preparation to just anybody. That's why you, and more than 2 million others, have purchased an Exam Cram book. As Series Editor for the new and improved Exam Cram 2 Series, I have worked with the staff at Que Certification to ensure you won't be disappointed. That's why we've taken the world's best-selling certification producta two-time finalist for "Best Study Guide" in CertCities' reader pollsand made it even better.

As a two-time finalist for the "Favorite Study Guide Author" award as selected by CertCities readers, I know the value of good books. You'll be impressed with Que Certification's stringent review process, which ensures the books are high quality, relevant, and technically accurate. Rest assured that several industry experts have reviewed this material, helping us deliver an excellent solution to your exam preparation needs.

Exam Cram 2 books also feature a preview edition of MeasureUp's powerful, full-featured test engine, which is trusted by certification students throughout the world.

As a 20-year-plus veteran of the computing industry and the original creator and editor of the Exam Cram Series, I've brought my IT experience to bear on these books. During my tenure at Novell from 1989 to 1994, I worked with and around its excellent education and certification department. At Novell, I witnessed the growth and development of the first really big, successful IT certification programone that was to shape the industry forever afterward. This experience helped push my writing and teaching activities heavily in the certification direction. Since then, I've worked on nearly 100 certification related books, and I write about certification topics for numerous Web sites and for Certification magazine.

In 1996, while studying for various MCP exams, I became frustrated with the huge, unwieldy study guides that were the only preparation tools available. As an experienced IT professional and former instructor, I wanted "nothing but the facts" necessary to prepare for the exams. From this impetus, Exam Cram emerged: short, focused books that explain exam topics, detail exam skills and activities, and get IT professionals ready to take and pass their exams.

In 1997 when Exam Cram debuted, it quickly became the best-selling computer book series since "...For Dummies," and the best-selling certification book series ever. By maintaining an intense focus on subject matter, tracking errata and updates quickly, and following the certification market closely, Exam Cram established the dominant position in cert prep books.

You will not be disappointed in your decision to purchase this book. If you are, please contact me at etittel@jump.net. All suggestions, ideas, input, or constructive criticism are welcome!


About the Author

April Wells is Senior Oracle DBA, Oracle APPS DBA, and DB2 DBA for CS Stars, an insurance claims processing and risk management ASP in Amarillo, Texas. She holds an Oracle 8, 8i, and 9i OCP and has taken numerous database and Oracle-specific classes. Her background includes experience with IMS databases; DB2; SQL Server; Oracle 8, 8i, and 9i; and dBase; working as a webmaster and Linux System Administrator as well as a Cobol programmer; Oracle Forms designer; and Visual Basic programmer.

April has presented at IOUG and has recently published Oracle 11i E-Business Suite from the Front Lines, Grid Database Design, and several articles on databases for InformIT. She is working on two more books (Grid Applications Design and Oracle 9i/10i Data Warehouse Field Guide).

She graduated with a BS in Information Science from the University of Pittsburgh's School of Library and Information Sciences and earned her MBA from the Texas A&M University System.

When she isn't working with computers, April enjoys hiking and biking with her family, reading, and family vacations (her two favorites are the Disney cruise they took to the Bahamas and the river rafting trip down the Colorado River through the Grand Canyon).


About the Technical Editors

Kimberly Floss has more than 15 years of experience in the Information Technology industry, with specific focus on relational database technology, including Oracle, DB2, Microsoft SQL Server, and Sybase. Kimberly has extensive experience performing as a DBA on mainframe, Unix, and Windows-based systems, as well as managing DBA teams supporting multiple database platforms. She also works as an Adjunct Professor, teaching SQL Programming/Database Administration at a community college.

Kimberly specializes in Oracle performance tuning and SQL tuning techniques, and is the author of Oracle SQL Tuning and CBO Internals by Rampant TechPress. She is president of the International Oracle User Group (IOUG), and an active member of the Chicago Oracle User Group and the Midwest Oracle User Group. Kimberly is also a frequent contributor to Oracle Magazine and Select Journal.

Rachel Carmichael has been an Oracle DBA for more than 12 years. She chaired the DBA Special Interest Group for the New York Oracle Users Group, developed the meeting agendas for the group, is both Chauncey and OCP certified, and has presented at various international and national conferences. She coauthored the Oracle Press books Oracle SQL and PL/SQL Annotated Archives, 1999, with Kevin Loney; Oracle DBA 101, 2000, with Marlene Theriault and James Viscusi; 9i Instant Scripts, 2001, with Kevin Loney and Megh Thakhar; and Oracle9i DBA 101, 2002, with Marlene Theriault and James Viscusi. She can be reached at wisernet100@yahoo.com.


Acknowledgements

I would like to thank

Carol Ackerman for being a great editor. You have been patient through all my adventures and all my trials. I enjoy working with you and look forward to continuing to do so.

Laura Lewin for being patient with me through the process of learning to work with an agent.

Rachel Carmichael and Kimberly Floss, my technical reviewers. The chapters that I barely remember writing while Adam was in the hospital were probably tough to read. Thank you for your patience. I promise, the Great Spirit will smile on you for this experience some day!


We Want to Hear from You!

As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass our way.

As an executive editor for Que Publishing, I welcome your comments. You can email or write me directly to let me know what you did or didn't like about this bookas well as what we can do to make our books better.

Please note that I cannot help you with technical problems related to the topic of this book. We do have a User Services group, however, where I will forward specific technical questions related to the book.

When you write, please be sure to include this book's title and author as well as your name, email address, and phone number. I will carefully review your comments and share them with the author and editors who worked on the book.

Email: | feedback@quepublishing.com
Mail: | Jeff Riley Executive Editor Que Publishing 800 East 96th Street Indianapolis, IN 46240 USA

For more information about this book or another Que Certification title, visit our website at www.examcram2.com. Type the ISBN (excluding hyphens) or the title of a book in the Search field to find the page you're looking for.


Introduction

Welcome to Oracle 9i: Fundamentals 1 Exam Cram 2. You are embarking on an adventure that has been taken by thousands before you. When you find yourself getting discouraged, take heart. If they can do pass the exam, so can you. You do have to understand that preparing for a certification exam is not an undertaking that you can attempt halfheartedly. Beware that preparation isn't easy, and it takes time and requires an investment in both money and effort.

If you are willing to take the process seriously and do what it takes to obtain the knowledge and experiences necessary, you can take and easily pass the certification tests. This book is designed to make it as easy as possible for you to prepare. But you have to take it the rest of the way.

Many software products, most operating systems, and nearly all commercially available databases now have a means by which those working with the product can improve their efficiency with the product and their ability to perform their jobs (for their prospective employers, for their current employers, or even just for themselves). Oracle is no exception. Oracle has not just one certification track for database administrators, it has three: Oracle Certified Associate DBA, Oracle Certified Professional DBA, and Oracle Certified Master DBA. Table I.1 gives you the examination and class requirements for each level of the 9i DBA Certification Track. As you can see in Table I.1, this test is a part of each of the tracks.

Table I.1. Oracle 9i DBA Certification Track

Exam Number

Exam Title

Required Correct Answers

Scored Questions

Passing %

Test Duration

OCA

You need to pass either 1Z0-001 or 1Z0-007 as well as 1Z0-131.

1Z0-001

Introduction to Oracle: SQL and PL/SQL

39

57

68%

2 hours

1Z0-007

Introduction to Oracle9i: SQL

40

57

70%

2 hours

1Z0-031

Oracle9i Database:

44

60

73%

1.5 hours

Fundamentals I

OCP = OCA + These two tests

1Z0-032

Oracle9i Database: Fundamentals II

49

63

77%

1.5 hours

1Z0-033

Oracle9i Database: Performance Tuning

38

59

64%

1.5 hours

8i to 9i OCP Upgrade

1Z0-030

Oracle9i Database: New Features for Administrators

37

53

70%

1.5 hours

The OCM certification requires the OCP certification plus two advanced DBA courses from Oracle University and a Practicum.

People may argue that passing tests isn't an adequate test of a database administrator's ability to do his or her job, but it is at least a measure of how well a person can recall critical and pertinent information in a stressful and less than optimum situation. No one can argue that taking a test is less than optimal. No one likes to take tests. At best, they are stressfulknowing that you could fail, knowing that you are being called on to remember things even when you know you are thoroughly prepared.

It doesn't matter whether it is your first test or your one hundred and first test, understanding the exam, the exam setting, and the testing software that you will be presented with will help you to better concentrate on the material that you are being tested on rather than the environment in which you find yourself.

What's more, knowing that you have mastered a few of the basic test-taking skills will help you recognize, if not fully anticipate, some of the tricks that inevitably find their way into some of the Oracle Certification test questions.


How to Prepare for an Exam

Knowing how to prepare for an exam such as this is half the battle.

One of the best ways to prepare, and I can't stress this enough, is to get a copy of the database and play with it. You can download the database, although it is in several rather large files, which take considerable time even over a dedicated high-speed connection, or you can buy trial soft-ware from Oracle Store (http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?a=b) and for less than $100 get full versions delivered to your door.

Install it, break it, fix it, and learn. It is useful to not just memorize information to answer the questions because often the questions are asked in such a way (or the answers are posed in such a way) as to make it exceptionally tricky to answer without having hands-on experience. And the experience of using the commands and actually working with the database and its associated commands and tools will be beneficial long after you have cleared all the exams.

Documentation

Get the Oracle documentation. These manuals, although not always an easy or entertaining read, are often the best resource to use when preparing for not only your tests but also for your life as a database administrator.

http://tahiti.oracle.com and http://otn.oracle.com/documentation/index. html are prime sources for the manuals for any given release of the software. The manuals are available in either PDF format, or as a web page in HTML format.

Tahiti maintains only database software, application server documentation, and Collaboration suite documentation on its site, whereas all the Oracle products' documentation, back several releases (including the database back through Oracle 7.3), is available through Oracle Technology Network (OTN). OTN requires you to sign up for a free membership to access its information (and many of the manuals through Tahiti are linked from the OTN site, so it is a worthwhile investment of 10 minutes), but that free membership also entitles you to a 20% discount on testing fees for the certification tests and access to a wealth of informative articles and access to downloadable software.

Metalink

Another resource at your disposal, if you are fortunate enough to be in an organization that has an Oracle support contract, is Metalink (http://metalink.oracle.com). On Metalink you can access technical documents and information on different aspects of database administration (architecture, administration, security, storage, and corruption just to name a few). It is an invaluable resource when you are learning about the Oracle database and is even more useful when you are troubleshooting issues when you are working as a DBA.

The manuals are also available on CD when you buy the software, even a trial set of the software, from Oracle Store.

Exam Prep Materials

There are many commercially available certification preparation materials. Many offer study guides (sometimes free, usually fee based) and test banks of questions similar to those found on the test, and often scaled-down versions of their test banks free of charge for download or online access. A simple online search will yield several dozen such organizations, including the following that I have used:

  • http://www.cramsession.com/

  • http://www.examnotes.net

  • http://www.whizlabs.com/ocp/oracle-dba.html

  • http://www.selftestsoftware.com/dept.asp?dept%5Fid=6000

    This is the software recommended on the Oracle Certification web site.

  • http://www.oracle.com/education/certification/index.html?content.html

    This offers a free demo version as well as the purchasable version.

Be careful what company you choose. Make sure that you are going to get what you have ordered and paid for. There are companies that charge you for software, offering lofty promises, and never deliver. As with anything, make sure that you are buying from a reputable company.

The Exam Cram 2 Book

By investing in this book, you have accessed another means by which you can quickly and efficiently work toward passing your certification. The Exam Cram and the Exam Cram 2 series have been a great help to countless certification candidates, not only in certification preparation but also as a concise reference to maintain in your library. This is a book that you will reach for to answer nagging questions that you know but can't quickly call to memory.

Classroom Training

If you have the money to invest, I highly recommend taking Oracle University offered courses, not simply for the information necessary for passing the exams but also for the experience. Although not everyone has $2000 to $3000 to invest in a single weeklong class, there is a lot to be learned in the classes. You learn not only from the instructors but also from others in the class and from the experience of really being able to break someone else's database in a controlled setting. You often don't know what you don't know until you are faced with either a question that has been asked by someone else in a class, or with a new situation with the database that you had never considered before.


Exam Format

The exams are all laid out similarly to each other. They have a set number of scored questions and a set time limit in which to answer them. After you finish the exam, you are (unless you are for some reason taking a beta exam where the score isn't returned for as long as three to four months) provided with your score at the end of the exam and told at that point whether you have passed or failed.

Beta exams are exams released several months before the "official" exams are ready. These exams have questions similar to the ones that will be on the official exam when it is released; however, there are more questions, and the time allotted for taking the exam is extended. For example, as of June 2004, the Oracle 10g upgrade beta exam has been announced. You have three hours to complete the exam, and you may have to wait up to 10 weeks for your score. Only the questions that make it into the official exam are scored, but you have no way of knowing what those question are. For the inconvenience, you only have to pay a fraction of the normal fee for taking the exam.

If you pass, you are given a passing certificate (your official certificate will be mailed to you later, along with a plastic card the size of a credit card for your wallet) that the testing center embosses with its stamp. If you fail, do not throw away the print out. It gives you directions on when you can retake the test (typically after 30 days) and tells you where you need to apply more study effort and which types of questions you missed, if not the actual questions that you missed. Use this paper as a study aid to direct your future study sessions.

Layout and Design of the Tests

The tests are primarily multiple choice, although I have taken a few tests that had a couple of completion questions on them. There are two types of questions using the multiple-choice layout: One has a single answer, and one has multiple answers.

The single-answer question has a radio button as the means to select the answer (see Table I.2). It lets you select exactly one answer, and if you select a second, it automatically unselects your original choice.

Multiple-answer questions, themselves broken down into two distinct categories, are answered by means of a check box. The first kind of multiple-answer question tells you, explicitly, how many different answers you are expected to have. You will have no fewer and no more than the specified number of answers. The question will have that number in the question (for example, choose two). If you attempt to provide more than the specified number of answers, it tells you that you can only give the specific number of answers requested, and if you want to answer something differently, you must unselect one that you have already selected. The other kind simply tells you to select all the answers that apply. This is my least favorite kind of question because you have to know when you are finished. I often find that I second guess myself and go back to make sure that I have gotten all the ones that I really wantand that I really want all the ones that I have selected.

Table I.2. Question Selection Options

Example

Description

Radio button

Check box

Finally, some of the questions require you to examine an exhibit to answer the given question. These exhibits may be a picture, an extended piece of code, or a multiline command that requires you to look carefully and to go back and double-check what they are asking. Occasionally, the exhibit spans more than one question. You can resize your windows on the monitor screen in such a way as to have both the question and the answers (scrollbars included) on the screen at the same time, or you can switch between the different full-sized windows to answer the relevant questions.


Testing Situation

When you arrive at the Sylvan Prometric Testing Center where you have scheduled your test, you will need to sign in with the testing coordinator. Be sure to have two forms of identification with you, at least one of which is a photo ID.

After you have signed in, the coordinator has verified your identity, and your specific time for testing has arrived, you will be asked to leave any books, bags, or other items brought with you in a designated area. You will then be escorted to a closed room, often with closed circuit TV camerasnot that this adds to the stress of the testing situation or anything.

In the room there will be, typically, from one to a dozen computers, separated from each other by dividers designed not as a sound barrier, but rather as a means to keep a tester at one workstation from viewing the happenings at another tester's workstation.

You will either be furnished with a pen or pencil and a blank sheet of paper that you will be required to turn back in at the end of the testing session or with a dry erase marker and a laminated piece of paper also to be turned in post test. On this sheet, you can write down as much information as you can recall from your study sessions, as much of the memorized information as you can, as many notes as you can remember or as will fit on the page. You can refer to this page at any time during the test, so make the best use of it you can. You can also make notes during the test if one question reminds you of something that might be a help on another question.

At least one wall of this room will consist of a plate glass window through which testing coordinators can monitor the testers to ensure that no one is talking to each other in the testing room. This is also the purpose of the closed circuit TV cameras.

Your testing coordinator will launch your preloaded exam, and you will be permitted to start the exam as soon as you are seated at the workstation. You will sign in with your testing ID number, and after affirming that you are ready, the test will begin. You will have 90 minutes from this point in which to complete the test. The test itself will provide you with a countdown timer so that you know how much time you have remaining for the exam and will also tell you on which question number you currently are working. There will typically be several unscored randomly selected questions on each exam, so you are likely to have more than 60 questions on the test that you take. These unscored questions are designed to let Oracle determine good questions for future tests. You will have no way to determine which questions will be scored and which will be unscored, so do your best on all questions.

Remember that the passing score varies with each exam. The passing score for test number 1Z0-031 is 44 out of 60 scored, or 73%.

Question Handling

All the Oracle certification exams are computer generated and are, typically, multiple choice, although I have seen a few completion answers. Although many people look forward to multiple choice, or multiple guess as we used to call them, these questions are constructed to fully assess your knowledge of the facts as well as to evaluate different circumstances.

Read over the test once, completely, answering only those questions whose right answer screams at you. After this initial pass through the test, you will know what the questions are and which questions you will have the most trouble with. On the next pass, or the next couple of passes, you can tackle those questions that make you stop and think, leaving the really difficult ones to the very end. This tactic will be particularly helpful in knowing exactly how many difficult questions you have left after you answered the ones whose answers were apparent to you. This way you can better get a feel for how you are doing on the test as a whole and make better decisions on how much time to dedicate to those really difficult questions.

Oracle has thought through the test design process (timed multiple choice), and the testing software is designed in such a way as to facilitate the timed multiple choice approach. At the bottom of every question is a check box next to the word "Mark." Checking this box allows you to quickly return to the marked question later.

Make good use of your ability to mark questions that you want to quickly and easily return to later. Don't mark every question. There will be many questions that you will be able to answer quickly with an assurance of the answer. Don't second guess yourself on these; going back and rethinking them will often result in your doubting your first instincts and changing the answers, only to realize after the test that you probably really didn't want to make that change. Not only will you likely change at least one answer that was right to something that was wrong, but you also will be wasting precious time. You are only allotted a finite amount of time, and you can't afford to waste that time going back over questions that you were nearly certain about the first time. You may find yourself at the end of the test with questions left and no more time.

Make sure that you read every word of every question completely. Do not get impatient and simply skim the question. You are likely to miss an important piece of information that could mean the difference between a right and a wrong answer.

The exams are designed in such a way as to challenge you with most questions having one or two obviously wrong answers and at least two that are nearly alike, and you have to read carefully to make the appropriate choice.

I cannot stress this enough. Read carefully and deliberately to avoid needless mistakes.

Understanding the Question

It is important that you not only read the questions carefully, but also that you make sure that you understand what the questions are really asking. It sometimes helps to draw out the question on the paper you are given, or to rewrite the answers in ways that you may remember from this book. The following list of suggestions may be helpful when you are working on understanding the questions that you are presented with.

As you read each question, try to rephrase that question in your own words. If you can do this, you will likely find choosing the right answer much easier.

After you have read the question the first time, reread every word again to make sure that you really understand what it is asking. This is particularly true if you have gone back to this question after having read the rest of the questions in the test. It is often the case that rereading the question after having had your attention on other questions makes the answer more obvious.

If you have returned to the same question more than a couple of times, make sure that you understand what it is about the question you don't understand. Rearranging the information so that you have narrowed down what you are missing may make the question make more sense this time.

If you find that you are approaching the end of your allotted time (keep an eye on that timer as you go) and you still have a few questions that you have left unanswered, it is better to go guess at an answer than to leave the question blank. They aren't going to not grade an unanswered question wrong (blank is equally as wrong as wrong is), and you have a statistical chance at guessing correctly.

Remember, with these questions as with any multiple-choice question, there are often one or two questions that you can eliminate immediately as being obviously incorrect. This process of elimination should leave you with the correct answer or answers, and maybe one or two other answers, depending on the question format, from which to make your ultimate choice. Eliminate these and concentrate on those that are left.

Obviously, wrong answers will likely have commands, tables, or views that are not only incorrect but also nonexistent.

Personal Readiness

Before you take this exam, before you take any of the Oracle exams, or in fact before you take any exam in life, it is important that you are confident that you are ready for the exam.

Before you read this book, take the self-assessment test included with this book to find out how much you already know. Compare your score on the self-assessment test with the score required for passing the certification test to determine how ready you really are for the test. Taking this test also allows you to determine those places where you are lacking in your knowledge and where you can best apply your efforts in studying for the real thing.

Take the test periodically during your studying to make sure that you are grasping the concepts in such a way that will allow you to answer the questions on the real test to the best of your ability and to give you the assurance that you are making the progress that you want to be making.

After you have read through the Exam Cram book and the supplementary materials at the end of every chapter and have taken the practice tests, you will have a fairly good idea of when you will be ready to take the official exam. Although you could practice until you have just achieved a passing score on the practice tests (73% to 75%), I would highly recommend (the voice of experience, here) waiting until you have achieved scores of at least 80% to 85% on the practice tests to make sure that you have a comfort factor to fall back on in the testing situation. Your stress level will be higher in the real test than it is sitting in an easy chair in the comfort of your home.

Physical Readiness

Physical readiness is every bit as important as mental readiness, perhaps more so. Make sure that you get enough sleep the night before your exam. You will be mentally sharper if you have had sufficient rest, and you will be sure that you won't fall asleep during the exam. Cramming all night the night before, trying to memorize as much information as you can at the last minute will do you much less good than one or two more hours of sleep will.

Don't go to the test center hungry; eat before you go. It would be counterproductive to overeat (it will take blood away from your brain and divert it to your stomach), but don't go with your stomach growling; it will distract you and any other testers in the room. Take with you a drink of water if it is permitted in your testing center. (The one where I take my tests provides paper cups and filtered water for exam takers; adequate hydration will make you more alert, as well.) Finally, overstudying can also be detrimental to your testing results. People often do better if they study until they feel comfortable and then take some time away from studying before the exam to take a walk, sit in the park, or just relax. Taking time to relax will likely lower your stress level, allow the knowledge that you have already gained to sink into your subconscious, and allow you to do better on the exam.

Now, let's look at the best way to use this book. The following section gives you some advice on how I would use this book.


Using the Book

And now, we are on our way.

Each chapter in this book follows a regular structure and provides graphical clues so that you can make note of important or particularly useful information.

This is what an alert looks like. Alerts stress particularly important concepts, terms, software, or activities that will most likely appear in one or more test questions.

Keep in mind, however, that not all information that will definitely be on the exam can be put into an alert; otherwise, the entire book would be an alert. Anything and everything in this book is likely to appear in a question on your exam.

This is how a tip will be formatted. Stay alert for tips. They give you testing hints and suggestions that will make your testing experience and future career as a DBA more successful.

This icon flags the presence of a potentially misleading question, often bordering on an outright trick question. They are calculated to trap you if you don't read them carefully and have a good understanding and working knowledge of the concepts that you are dealing with. Although there are not many of these in the Oracle certification exams, they do occasionally make an appearance on the tests, and knowing that they might be coming will help you be better prepared.

The topics in this book are designed to build on each other. Some of the information in later chapters makes more sense if you have already read the earlier chapters. Because the information is reused from one chapter to another as a foundation on which to build, for the first pass through the book, I would suggest reading it front to back. If after the first pass you still need more work in one or more areas, and this will likely be the case, you can then go back and concentrate on those areas.

Opening Hotlists

Every chapter opens with a set of hotlists: "Terms You'll Need to Understand" and "Concepts You'll Need to Master." They let you know what to expect in the given chapter, what topics are covered, and what terms you need to be comfortable with by the time you have mastered the chapter.

Terms

Every chapter has its own vocabulary, grammar, set of terms, and syntaxes that you will need to master to ensure a successful test-taking experience.

Tools

Some chapters have a set of new tools that you must become comfortable with to master the chapter. It is important that you familiarize yourself with these tools for a successful testing experience.

Techniques

Every chapter has its own set of techniques, those processes that make up the meat of the test. Make note of the syntaxes used in the examples and work through them on your own. These may be as simple as budgeting your time and making the best use of the resources that you have, to the trickier aspects of deciding which of Oracle's many features to use in any given situation.

Other Tools in the Book

This book has several other tools that will help you prepare for your exam. The use of these tools will help you to better prepare and to feel more confident in your preparation.

Practice Questions

At the end of every chapter are several questions designed to make sure that you understand the concepts the chapter covered. Immediately following the questions is the correct answer along with an explanation of why it is correct and the incorrect answers along with explanations of why they are incorrect. Check yourself after you have read the chapter, and after a few days, go back and check yourself again. In this way, you can make doubly sure that you understand the material as you are covering it.

Practice Exams

Two practice exams are at the end of the book. They are designed to be similar to the actual exams. Time yourself taking them to get a feeling for how long it takes you to answer them.

I have used this type of book in preparation for certification exams before, and I have found it useful to not mark the practice exams as I take them but either to copy the questions and mark up the copies or to just write down the answers on another piece of paper. This way I don't let the marks on the exam influence my decisions the next time I go over the questions.

The first time, take your time. Read the question. If you can answer the question right off, great! If not, go back and check on the information and make sure that you understand what is being covered by the question.

After you understand the questions, time yourself taking the exam. This gives you a feel for how you will react during the actual exam.

Answer Keys

Answer keys are another great resource included in this book. Not only do they give you the correct and incorrect answers, but better, they give you the reasons that the answers are right or wrong. Some of the questions are designed to have several nearly correct answers. The answer keys explain the reasons that the incorrect answers are wrong.

Cram Sheet

The exam cram sheet is designed as a mobile study tool. It is perforated so that you can easily remove it from the front of the book. It contains key points in a concise format that allows you to quickly recall and clue yourself on points that will be on the exam. These sheets have been the reason that several people have gotten one or two extra questions rightthey recalled having seen the point on the cram sheet. Take the sheet to your exam appointment and give it a quick glance through right before your exam to refresh your memory.

The Author

If you want to use me as another resource, feel free to email me. I can be contacted at oracle_cram@yahoo.com.


Self-Assessment

I have included a Self-Assessment section in this Exam Cram 2 book in an attempt to help you to determine your own readiness to tackle the Oracle Certified Professional (OCP) 9i Database Administrator certification track. It also gives you a general idea of what you need to do to master the topics covered in this book: the requirements for the 1Z0-031 Oracle 9i Fundamentals 1 test, the second in the series for both Oracle Certified Associate (OCA) and Oracle Certified Professional (OCP).

People go into this process with many different expectations and impressions. This self-assessment helps you to determine whether your expectations are realistic and gives you a better idea of what an ideal candidate might look like.


In the Real World

Only you know what you are expecting from your certification or from the exam process. Only you know what you are trying for, what you hope to prove, if only to yourself. Many people get their certification because they know that many job descriptions cite the need for certification in the requirements for applying for the job. Many people mistakenly think that certification in itself will be the magic silver bullet that allows the candidate to walk in and, day one, single-handedly vanquish all demons from the databases.

Other people certify because their current positions have begun to expect it from them. It is part of the performance evaluation; they are trying to further their career or other personal career motives. Many companies not only reimburse for certifications, they pay bonuses for passing all the tests and getting the certification.

Still others do it for purely personal reasons. This was my initial reason for seeking certification. I didn't like to know that other people had the attitude that they could do it and I hadn't done it yet, so that meant that somehow they were better than I was. After I got my certification, my attitude changed, even though theirs didn't, but by that time I knew I could pass the tests, and their opinion of me no longer mattered to me.

Whatever your reason, it is a fact that you will find the job market far more open to you if you have your certification, particularly if you are certified in one of the more recent releases or are certified on more than one release. Fortunately, Oracle has made it less difficult (I promise you, not easy) to upgrade your certification from one release to the next in a single upgrade test, so you don't have to go through the entire certification processes every time Oracle has a new release of the software. This is primarily because the underlying architecture and structure is similar enough that the concepts don't change, only the bells and whistles have been enhanced and improved, and a few older features have been done away with in favor of the newer way of doing things.

Take a jaunt down Monster.com or one of the other job search sites, and you will find that at least a quarter of the Oracle DBA jobs listed have certification stated as an official requirement of the job. Others suggest that those candidates who have achieved certification are looked on favorably, and still others are looking for it without actually coming out and requesting it.


The Ideal Candidate

Did you ever wonder what the ideal OCAOCP candidate might look like? Looking at the people who have already received their certification isn't likely to tell you much, because we don't live in an ideal world, and very few of those achieving certification would be considered an ideal candidate. If you look at what the "ideal" candidate looks like, it may be intimidating enough for you to change your mind about pursuing certification. But fear not! Be undaunted! Probably only 5% to 10% of the people who have gone where you are going now can claim to be ideal.

The good news is, if you are willing to go through the process and take it seriously, you can do what it takes to obtain both the necessary experience and the knowledge to not only take the exams but pass them as well. Exam Cram 2 books are designed especially to help to make the process as simple as possible.

The ideal certification candidate has the following knowledge and experience.

  • Either academic or other professional training in relational databases, SQL, tuning, and backup and recovery, preferably in Oracle 9i. Although a background in previous versions (such as Oracle 8i) is helpful, it is important that you have a good understanding of the version that you are testing on.

  • At least three to five years of hands-on professional database administration experience. This experience would include installation and upgrading of core Oracle executables; creation of one to several databases; tuning; troubleshooting database issues and connection problems; creating users, indexes, tables, tablespaces, and other structures; and managing backups and (more importantly) recovery scenarios.

What do real candidates look like? They are people with no experience. They have been users and administrators of relational databases for more than a decade. They are male and female, young and old, gainfully employed in their field, currently unemployed, or hoping that certification will help them to get that important first job or at least their foot in the door. The only thing that the real candidates, either working toward certification or already certified, have in common is that they are going to take, or have taken, the certification tests.


Put Yourself to the Test

The following questions and observations are not designed to help you decide whether you really want to be certified. If you weren't sure of that, you probably wouldn't have read even this far in this book. They are designed to help you to determine how much real work you will face in this pursuit of the elusive OCP prize and what other information you should seek in your quest.

Be honest with yourself about the answers; you are the only one who will see them or know the answers anyway, and if you aren't honest with yourself, you are the only one who will face the consequences of the answers.

Educational Background

Formal education is one important aspect of determining your readiness for the exam. This does not necessarily mean that you must have a degree or that your education must have come from a university or even directly from Oracle (although either of these helps). It only means that you have spent time in pursuit of the information.

  1. Have you ever taken any computer classes, either at a university, online, or independently? [Yes or No]

    If Yes, proceed with questions 2 through 4. If No, continue to question 5.

  2. Have any of your classes been on relational databases or relational theory? [Yes or No]

    If yes, you should be okay with the majority of the Oracle documentation, the concepts covered in this book, and the information included on the exams. If it has been a while since you have worked with relational databases or since you have taken such a class or read anything on it, you might want to brush up on some of the basics and the terminology. It comes back quickly.

    If No, you might want to look at reading some of the broad books in the area of Oracle, particularly a good Database Administration book such as Oracle 9i The Complete Reference by Kevin Loney and George Koch (McGraw-Hill 2002), or review other titles available at any bookseller. Not only will the additional reading provide you with needed background on the concepts and vocabulary but also will prove to be a valuable reference going forward.

  3. Have you taken any database administration classes? [Yes or No]

    If Yes, you should have a general idea of how things work and what processes are involved in database management systems.

    If No, you might want to do some searches on your favorite search engine and read some of the exceptional white papers and presentations that have been done on the subject of Oracle 9i administration, or visit Oracle TechNet (http://technet.oracle.com) to see what might be on its site in the line of online training (some are even free) or articles and white papers. You can even download the Oracle 9i database administration manual to peruse at you leisure.

  4. Have you done any reading on relational databases? [Yes or No]

    If Yes, review the requirements for the exam and the suggestions for questions 3 and 4. If you are comfortable with those, you can easily go on to question 5.

    If No, pursue the recommendations on further reading for both questions 3 and 4. A more well-rounded background will be an asset not only in your exam taking experience but also in your future career.

Hands-On Experience

A big key to your success on not only this exam but all the Oracle exams as well is hands-on experience with the product. This is true not only for the exam process but also for your future employment. It is not necessary that you have years of experience administering high transaction or very large databases in a production environment to meet this requirement. It is only suggested that you have interacted with the software on more than a cursory level.

  5. Have you installed and worked with (installed, configured, and examined) the Oracle 9i release 2 database software? [Yes or No]

    If yes, you have a head start on understanding what is going on with the product. Now you need to make sure that you understand the exam objectives and start looking at what it will take to pass not only this exam but the subsequent ones as well.

    If No, seriously consider getting the installation media and practicing with the product before you have to face the exam situation. It is an advantage to have worked and interacted with the product hands-on before attempting the certification exams. Proceed to the next section about how to gain some hands-on knowledge.

Download the candidate certification guide, objectives, and other information about the exams from the Oracle training and certification page on http://www.oracle.com/education/certification/index.html?content.html.

You can download the database, although it is in several rather large files that take considerable time to download even over a dedicated high-speed connection, or you can buy trial software from Oracle Store (http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?a=b) and for less than $100 get full versions delivered to your door. Install it, break it, fix it, and learn.

Install it, configure it, work through some of what you will learn in this Exam Cram 2 book, as well as the following exams.

Whether you have taken formal training classes to help you to prepare for the exams or are just using written material to study from on your own, preparation is absolutely essential.

The $125 fee for each and every try, regardless of your success or failure, is a bit expensive if you have to pay it more than once for a test. And even if your company is reimbursing you for the exams, they won't likely reimburse you for failing one. Having to pay for the same test more than once is at the very least disheartening. You will, therefore, want to do everything that you can to increase your chances of passing the test the first time. Studying will help you to improve those chances.

Take the practice exams included with this book along with the sample questions at the end of each chapter. If you don't score well on the chapter questions, study more, concentrating on those areas where you performed poorly.


Assessing Your Readiness for the Exam

There are, included with this book, several exam-like questions at the end of each chapter and sample exams at the end of the book. Work through the questions at the end of the chapters and through the exams at the end of the book and, if you don't score at least an 85%, investigate those places where you missed questions. Look at the resources in the "Need to Know More?" sections, and look up the topics on your favorite search engines. There are many resources that you can use, including other practice test resources that can help you with your adventure.


Onward Through the Fog

Now that you have determined that you are ready, looked at supplementing your knowledge with more information and additional study material, and attempted to acquire hands-on experience, you are ready to take the practice exams. After you have achieved a comfort level in the material, you will be ready to take your exams and to achieve your goal.

Let the adventure begin…


Chapter 1. Oracle Architecture Components

Terms you'll need to understand:

  • Oracle Server

  • Oracle database

  • Oracle instance

  • System Global Area

  • Program Global Area

  • Log writer

  • Database Writer

  • Archiver

  • Checkpoint

  • System Monitor

  • Process Monitor

  • Extent

  • Segment

  • Data Block

Concepts you'll need to master:

  • Describe the difference between a database and an instance.

  • Describe the physical structures associated with the Oracle database.

  • Describe the logical structures associated with the Oracle instance.

  • Describe the memory structures in an Oracle instance.

  • Describe and understand the different processes associated with an Oracle instance.

  • Describe what takes place when a user connects to an Oracle instance.

One of the first things that you need to become comfortable with when you plan for this and all the Oracle exams is the architecture of the Oracle server, the instance and the database. After you have a handle on the architecture and its vocabulary, you will have a solid foundation on which to build for this and the other exams. We start our discussion of the Oracle architecture with the broadest category, but the one most often confused by new administrators and experienced DBAs alikethe difference between the database and the instance. Many people use these terms interchangeably, but they are distinct and different.


Database Versus Instance

People, even experienced DBAs, dealing with Oracle often confuse the idea of what a database is with what an instance is.

Oracle Server

The files, processes, and memory structures, whether used when processing SQL statements or not, make up the Oracle Server. The Oracle Server consists of the Oracle instance and the Oracle database.

Database

An Oracle database consists of the physical datafiles and the other physical supporting files that assist in the controlling of the access and operation. The collection of data is treated as a single unit. To interact with these files, and the information in these files, you need the assistance of the operating system (for resources such as memory and I/O subsystem) and a set of specific Oracle-created processes.

Instance

An Oracle instance, the set of Oracle-created processes and specific memory allocation that allow users to access the information stored in the database's datafiles, performs the work necessary for the efficient maintenance of the system and the efficient access and manipulation of the information resident in the database.

Although you often hear people talking about a database being "up" or "down" (or…shudder…"crashed" for that matter), it really means that the instance is up, down, or crashed. Physical files can be corrupt or deleted, but only the processes of the instance can be up or down.

Data Blocks

The smallest logical component of an Oracle database is the Data Block, often also referred to as Oracle blocks, and the smallest unit of space allocation possible. Data Blocks are defined in terms numbers of bytes, for example 2KB, 4KB, or 8KB. The database's standard block size is set in the DB_BLOCK_SIZE initialization parameter and is allocated in powers of 2KB, typically up to 32KB.

Although you add space to a database in bytes, kilobytes, or even megabytes or gigabytes, because a data block is the smallest unit of storage that Oracle can manage or retrieve in a read operation, it is important that you work with your system administrator to determine the disk block size (covered in the following section) of the operating system and make the data block size a multiple of the operating system's disk block size. This allows you to take best advantage of the underlying operating system's capability to read and write larger chunks of data to disk in a single I/O operation.

It is important to note that in prior releases, Oracle allowed only one block size to be in a database. There was no facility for allowing multiple block sizes in the same database. Oracle has provided much flexibility and ease of management in providing this capability.

Data blocks are made up of the following pieces (see Figure 1.1):

  • Block header A 48-bit integer used for checking the block integrity

  • Free space The amount of space left in the block that can be allocated to additional rows of row data, or to expansion of existing rows

  • Row data The data stored in the tables to which the given data block belongs

Figure 1.1. Components of Oracle data blocks.

Block Size Choices

Carefully consider the purpose of your database at its creation time. Its purpose will impact the standard block size that you will want, and the standard block size is difficult to change after the database's creation and requires a total rebuild of the database to make this change. Typically, smaller block sizes are used for systems that have smaller rows, and you have inserts, updates, and deletes occurring frequently, as in an Online Transaction Processing (OLTP) system. Larger block sizes are usually used for systems where there are many large queries but less frequent updates, as in a data warehouse or an Operational Data Store (ODS) or a Decision Support System (DSS).

Although Oracle's default block size, if the DB_BLOCK_SIZE is left unset, is 2KB, even a busy OLTP environment would benefit from a block size of around 8KB.

Oracle's default block size is 2KB if the DB_BLOCK_SIZE initialization parameter is left unset in a manual database creation. In an Oracle database created with the Creation Assistant, the default block size is 8KB if not specified.

If you find that you have need for multiple block sizes in a database, with release 9i, Oracle provides that capability as well. You can now allocate four nonstandard block sizes in addition to the database's standard block size. It is important to remember that you have to also configure the corresponding DB_n K_CACHE_SIZE to go along with the nonstandard block sizes that you intend to use.

Cache sizes can be set to any size but will be rounded to the nearest granule. A granule is either 4MB for a System Global Area (SGA) with a total size less than 128MB, or 16MB for a larger SGA. We cover the SGA later in this chapter. The standard buffer cache is set using the DB_CACHE_SIZE parameter and, if left unset, defaults to 48MB. Individual buffer caches (covered in more detail later in the chapter) need to be defined for each nonstandard block size before that block size can be used to define a tablespace. These additional buffer caches are set up with the following initialization parameter.

A database with an 8KB standard block size might have the following nonstandard buffer cache sizes:

  • DB_2K_CACHE_SIZE = 16MB

  • DB_4K_CACHE_SIZE = 16MB

  • DB_16K_CACHE_SIZE = 16MB

  • DB_32K_CACHE_SIZE = 16MB

Again, each cache to be used must have at least one granule assigned to it, and the instance has to be restarted before the changes to these parameters can take effect.

Although Oracle 9i has been widely publicized as a dynamic database with parameters that mean that the instance no longer has to be restarted for changes to take place, this is not necessarily true in all cases. A significant number of initialization parameters still are static and do require the data-base to restart for their changes to take place. DB_n K_CACHE_SIZE is one such parameter.

Before a DB_nK_CACHE_SIZE parameter can be reset back to 0MB, you need to make sure that there are no online tablespaces using the corresponding nK block size.

Now you can create a tablespace using the nonstandard block size:

CREATE TABLESPACE my_smallblock_tblsp BLOCKSIZE 2048;

The ability to add four additional nonstandard block sizes to the database, in addition to the standard data block size, gives you a total of five distinct block sizes to use in a single database and instance.

Disk Blocks

The disks on which the Oracle blocks reside are also divided into areas of contiguous storage of bytes, called disk blocks, or OS blocks. Typically, these blocks are referred to by the number of bytes involved rather than the number of KB. Different operating systems have different standard block sizes. Some are 1024 (1KB), some 512 (.5KB), and others 4096 (4KB) or even 32768 (32KB) or more.

Extents

Several contiguous data blocks make up an extent. Oracle allocates an extent only if it can find sufficient contiguous data blocks to allow for the extent to be created in a single allocation.

Tablespace type plays a part in determining how Oracle allocates extents. Dictionary managed tablespaces allow you to specify the beginning allocation of space and the future increments as necessary.

The CREATE TABLESPACE statement, for a dictionary managed tablespace, includes the storage parameter specifications starting with Default Storage and including the keywords INITIAL and NEXT, MINEXTENTS, MAXEXTENTS, and PCTINCREASE.

CREATE TABLESPACE mytblspace
    DATAFILE '/mydatabases/mydb1/mytblspace01.dbf' SIZE 500M
    DEFAULT STORAGE (
        INITIAL 50K
        NEXT 50K
        MINEXTENTS 2
        MAXEXTENTS 50
        PCTINCREASE 0);

Locally managed tablespaces use a simpler method, allocating uniform extent sized, chosen automatically by the database. Not only do you not have to worry about setting the initial and next extent size, if you do set the size in an allocation, Oracle ignores what you set.

All database objects get allocated a certain amount of space when they are created. This initial space allocation is called the initial extent. After an extent is allocated to a table or an index, the extent remains allocated to that particular object until either that object is dropped from the database, at which time, the extents revert back to the pool free space waiting to be allocated in the database, or the object is truncated with the DROP STORAGE clause or the REUSE STORAGE clause associated with the truncate command.

Segments

Segments are made up of two or more data blocks that are themselves allocated to an extent that is allocated to a specific logical structure. A single segment can span multiple datafiles belonging to the tablespace to which the segment also belongs. Table 1.1 provides a summary of the common segment types along with their descriptions.

Table 1.1. Common Segment Type Descriptions

Segment Type

Description

Data segment (or table segment)

All nonclustered tables have data segments; all table data is stored in the extents in the data blocks of data segments. Each partition in a partitioned table has a data segment, and each cluster has a data segment. In the case of a cluster, the data of every table that is a member of the cluster is stored in that cluster's data segment. These segments contain a header block that serves as a space directory for the segment.

Table segments hold onto their previous storage settings until either they are dropped or the table is truncated with the DROP STORAGE clause or the REUSE STORAGE clause associated with the truncate command.

Index segment

Each index has an index segment in which all its data is stored. For partitioned indexes, each partition has its own index segment. These segments hold onto the space that has been allocated to them until they are dropped or until the index is truncated with the DROP STORAGE clause or the REUSE STORAGE clause associated with the truncate command. If they are sized incorrectly, fragmentation can occur and slow the database performance.

Temporary segment

Temporary segments are created by Oracle only when a SQL statement is run that needs a temporary work area (typically used for sort work that can't be run in memory) in which to complete its execution. When the statement requiring that space finishes execution, the extents in the temporary segment are returned to the system for future use. These should never be created in the system tablespace.

Rollback segment

If you are operating your 9i instance in automatic undo management mode, the database server transparently manages undo space using tablespaces. If you are still operating your 9i instance in manual undo management mode, one or more rollback segments need to be created and managed by the database administrator to temporarily store the information that allows the instance to undo any active transactions.

Regardless of the mode of undo management, the segments in question are used during database recovery, to generate a read-consistent picture of the data in the database or to roll back any uncommitted user transactions or for queries that need a read-consistent view of the data.

LOBnn segment

If there are LOBs (or large objects) such as text documents, videos, or images, these segments store pointers to the large objects in the datafiles.

Cache segment

If a table has a nested table as a column, a cache segment is used to store the user-defined embedded table.

Bootstrap segment

This segment is created by the sql.bsq when the database is created.

Each database object created has its own segmentevery table, every index, everythingand every segment is named after the object it was created for. Any space that gets allocated for these segments remains allocated, even if the object is truncated (unless you specify either TRUNCATE with REUSE STORAGE or trUNCATE with DROP STORAGE), until that object is deleted from the database.


Datafiles

Datafiles are the files stored on disk that hold the data in the database. They are the physical structures in which Oracle stores information. Datafiles are created and manipulated indirectly when the CREATE TABLESPACE command or the ALTER TABLESPACE command is issued. A datafile takes up exactly the amount of space specified in the creation statement, regardless of whether a single object is created in the associated tablespace. Any datafile can belong to exactly one tablespace.

Tablespaces

Databases are made up of tablespaces, purely logical constructs that allow you to group related logical structures together. Tablespaces, the primary logical structure of the database, are commonly used as a means to group together all objects common to a single application to simplify some administrative operations; however, you do not have to only store related objects in a given tablespace.

Any particular tablespace is made up of one or more datafiles, and the combined size of all the datafiles associated with a tablespace is the total storage capacity of that tablespace.

The following sections discuss some special case tablespaces. Although they share many of the same characteristics as "normal" tablespaces, these have either special features or special purposes.

System Tablespace

A database must have at least one tablespace, the system tablespace, for the database and the associated instance to be created. The system tablespace holds the data dictionary information and is required for the database to build. You can never drop the system tablespace.

Temporary Tablespace

Temporary tablespaces are created so that large sort jobs that won't fit into available memory have somewhere to perform their work. If a temporary tablespace is created at database creation time, it is automatically assigned to users as their default temporary tablespace when the users are created.

Undo Tablespace

For the instance to take advantage of automatic undo (the Oracle supported means of undo as opposed to the previously preferred manual rollback segment managed undo), the database needs to have an undo tablespace. An undo tablespace must be created as an UNDO TABLESPACE for Oracle to use it as such. This tablespace houses the undo information for transactions and provides the facility for a read-consistent image of the data in the database. The following is the command that should be used to create an undo tablespace.

The only tablespace that Oracle creates automatically is the system tablespace. Although it is created automatically, you do, however, have to inform Oracle where you want the datafiles associated with the system tablespace to be located.

Figure 1.2 shows the relationship between data blocks, extents, segments, datafiles, and tablespaces.

Figure 1.2. Relationship between structures in the database.

Synonym

Synonyms are, simply, aliases that point to database tables, views, other synonyms, and PL/SQL program units. When a synonym name is used, Oracle automatically replaces its reference with the name of the object on which the synonym is defined. Oracle first checks to see whether any Private synonyms are defined (those created in a specific schema and accessible only by the schema that owns it). If Oracle can't find a Private synonym, it then looks for a Public synonym (those owned by the PUBLIC schema, open and available for reference by all database schemas).

Schema

A schema is a collection of database objects all owned by a database user. A schema has the same name as the user who owns the objects. A user can exist if no schema objects exist, but a schema cannot exist without an associated user account.

Schema Objects

Schema objects are logical structures that belong to a schema. These objects either directly refer to the database's data or are logical constructs that allow you to interact with the data (as in the case of views or synonyms).

Table

Tables are the basic unit of storage for data in the database. Tables are made up of rows and columns.

Index

Indexes are considered optional structures in the database, built on one or more columns in a table. Oracle automatically maintains the indexes when the data in the table is altered, inserted, or deleted. Their purpose is to improve performance of data retrieval. Similar to the index in this book, an index in the database allows the instance to assist the user in more quickly finding the information requested in a select statement. Indexes should be used judiciously and based on the requirements for the database in question. They can have adverse effects on performance in updates, inserts, and deletes. If you have an OLTP database where there are many of these transactions, indexes could prove to be bottlenecks in your processing.

View

Views are customized representations, often considered to be a stored query, of data that exist in one or more tables or other views. Views don't actually contain data, but rather derive data from the underlying tables on which they are based each time they are accessed. These underlying tables are referred to as the base tables of the view. Views can be queried and, depending on the type of view, inserted into, deleted from, and updated, with some restrictions. Because views are only conceptual representations of underlying data, operations that you perform are performed on the base tables of the views. Views enable you to hide the complexity of the data and of the queries on which they are based, freeing end users from the need to have as deep of an understanding as they would if they had to construct the query on their own.

Redo Log Files

Every Oracle database has a set of two or more redo log files. The set of files is collectively known as the redo log for the database and is made up of redo entries (also known as redo records).

The primary function of the redo logs is to record all changes made to any data in the database. If the instance experiences a failure preventing the modified data from being permanently written out to the datafiles, those changes can be obtained from the redo log when the instance is restarted so that work is not lost.

To protect against any failure that might occur involving the redo logs themselves, Oracle allows you to, and in fact suggests that you do, use multiplexed redo logs so that two or more copies of the redo logs can be maintained on different disks. This is to ensure that, in the event of disk failure, at least one copy of the redo logs is retained.

The information located in a redo log file is used to recover the database from either a system or media failure that would prevent the database data from being written to the datafiles before the instance stops. An example of this would be an unexpected power outage that terminates the instance's operation causing the data in memory to not be written out to datafiles. Ordinarily, you would think that the data that hadn't been written would be lost. However, this lost data can be recovered and written out to the correct data files when the instance is reopened after power is restored. By allowing and facilitating the information in the most recent redo log files to be written out to the database's datafiles, Oracle restores the database to the time when the power failure occurred. For this example, we assumed that the redo log buffers have had all their changes written out to the online redo log files on disk. If this is not the case, for example in a sudden loss of power to the server, there is no way to recapture the data that never made it from the buffers to the redo log files.

The process of reapplying the data located in the redo log during a recovery operation is called rolling forward.

Control Files

Every Oracle database instance combination has a control file (or a multiplexed control file to protect the control file against corruption or disk failure). A control file contains those entries that specify the physical structure of the database, including the following information:

  • Database name

  • Names and locations of all datafiles, the undo tablespace files, and redo log files

  • Time stamp of database creation


Memory Structures

Oracle's memory structure consists of two memory areas known as the System Global Area (SGA) and the Program Global Area (PGA) (see Figure 1.3).

Figure 1.3. Memory structures and processes of Oracle.

System Global Area

The SGA is the shared memory region that contains both data and control information for one Oracle instance. If there is more than one user connect to the instance, the SGA and the data allocation in the SGA are shared among all connected users. For this reason the SGA is often referred to as the Shared Global Area. Oracle allocates the entire SGA when an instance starts and deallocates the memory (freeing it for the operating system to reclaim) only when the instance shuts down. Each instance has its own SGA.

The SGA has read/write permissions for every user connected to the instance. Users are not the only ones able to read from and write to the SGA, however. Oracle itself writes certain things to the SGA outside the user query results. You, as the DBA, can pin stored procedures in the SGA. You can also pin small lookup tables in the SGA so that they don't get aged out and so that their access is speeded up. The SGA is allocated at instance startup and remains allocated until the instance is shut down; it is a fundamental component of every Oracle instance.

A granule, a contiguous unit of virtual memory allocation, is how the memory allocation in the SGA is tracked. If the SGA_MAX_SIZE parameter of the database is set to under 128MB, a granule is 4MB; otherwise, it is 16MB. It is on the granule boundary that the components that make up the SGA are allowed to grow and shrink to.

The SGA contains the database buffer cache, the redo log buffer, and the shared pool. The following sections explain what each portion's function is.

Database Buffer Cache

The database's buffer cache is that portion of the SGA that holds the most recent copies of data blocks that have been read from datafiles. The set of database buffers in an instance is the database's buffer cache. The buffer cache contains modified as well as unmodified data blocks. All user processes concurrently connected to the instance share access to the database buffer cache.

The most recently used data is kept in this memory area. Fewer reads from and writes to disk are necessary, and this can contribute significantly to performance improvements. The most recently used data is often the most frequently used data. Because it is accessed frequently, it is usually among the most recently accessed.

Redo Log Buffer

The redo log buffer is a circular buffer in the SGA whose job it is to hold information, stored in redo entries, about changes made to the database. Redo entries contain all the information necessary to reconstruct (or redo) all the changes made to the database by any INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operation that has occurred in the database. Redo entries are used for database recovery, if necessary, and are copied by an Oracle server process from the memory space to the redo log buffer in the SGA. These entries take up continuous sequential space in the circular buffer and are written out to the redo log files on disk by Log Writer process (LGWR) before they are overwritten by another set of entries.

Shared Pool

The shared pool portion of the SGA contains two major areas and is sized using the parameter SHARED_POOL_SIZE. The two areas are as follows:

  • The Library Cache Includes the shared SQL areas, private SQL areas, PL/SQL procedures and packages, and control structures

  • The Dictionary Cache SGA memory area containing information on various data dictionary objects that contain data about tables, indexes, users, and other database objects

Oracle represents each SQL statement it runs with a shared SQL area and a private SQL area and recognizes when two different users are executing the same SQL statement. When this happens, Oracle reuses the shared SQL area for those users. However, each user must have a separate copy of the statement's private SQL area.

In the following section, we will look more closely at the shared SQL areas.


Shared SQL Area

A shared SQL area contains the parse tree and execution plan for every given SQL statement being run in the instance. Oracle conserves memory by using just one shared SQL area for SQL statements run multiple times. This often happens when many users run the same application or when one user runs the same SQL statement repeatedly (including the same bind variables), using slightly different values for some of the where clauses.

Oracle allocates additional memory from the shared pool to the shared SQL area whenever a new SQL statement is parsed and stores that SQL statement in the shared SQL area. The size of the memory that gets allocated depends on the size and the complexity of the statement in question. If the entire shared pool has already been allocated to parsed SQL statements, Oracle can deallocate statements from the pool by using a modified Least Recently Used (LRU) algorithm repeatedly until there is enough free space for the new statement's shared SQL area. If Oracle deallocates a shared SQL area, the SQL statement associated with that shared SQL area must then be reparsed and reassigned to the shared SQL area the next time it is executed.

Shared PL/SQL Area

The shared PL/SQL area stores and shares the most recently executed PL/SQL statements. Any parsed and compiled program units as well as procedures, functions, packages, and triggers can be stored in this area. Any program unit not frequently used is eventually aged out using the LRU algorithm.

Data Dictionary Cache

The data dictionary cache (also referred to as the dictionary cache or row cache) is a collection of the most recently used definitions in the database. The information stored in the data dictionary cache comes directly from the data dictionary views and their underlying tables. Information stored in this area includes information about database files, tables, indexes, users and their privileges, and other database objects.

During the parse phase of any statement, the server processes look at the data dictionary for information that might be needed to resolve object names and to validate a user's privileges to access any given object. The caching of this information into volatile memory improves response time for queries.

Large Pool (Optional)

The database administrator can configure an optional memory area in the SGA called the large pool to provide large chunks of memory allocations for I/O server processes, for processes connected directly to real application clusters, and for backup and restoration operations. It can also be used to relieve some of the burden placed on the shared pool. The large pool does not user the LRU algorithm to age information out.

Java Pool

Another optional memory area that the database administrator can configure is the Java Pool. The Java Pool is necessary when you are installing, compiling, and using Java in the database. The default setting for Java Pool is 20MB, which should be adequate unless you are using either shared server architecture, or have Java-intensive applications. If either of these is the case, you might want to expand the Java Pool to up to 100MB. Java is stored much the same way as PL/SQL in the database tables.

Next, we will look at yet another memory region of the Oracle instance, the Program Global Area.


Program Global Areas (PGA) Overview

The Program Global Area (PGA) is a memory region that contains data and control information for a server process. It is a nonshared memory created by Oracle whenever a server process is started and access to it is exclusive to that server process. Oracle code acting on behalf of the process is the only thing that has read or write access to the PGA.

The PGA is allocated when the server process is started, and the total PGA memory allocated by each server process attached to an Oracle instance is referred to as the aggregated PGA memory allocated by the instance.

Although the content of the PGA memory varies, depending on whether the instance is running the shared server option, the PGA memory can be classified as containing the private SQL area and work areas.

Private SQL Area

The private SQL area contains bind data information and runtime memory structures. Each connected user session that issues a SQL statement has its own private SQL area in the PGA regardless of its ability to use a single shared SQL area.

The location of a private SQL area depends on the type of connection established for a session. A session connecting through a dedicated server has its private SQL areas located in the server process's PGA. A user session that connects through a shared server architecture is given a part of the private SQL area that is kept in the SGA.

Dedicated Server

In a dedicated server architecture, every user who connects to Oracle has a personal dedicated connection handling the data retrieval from disk into the buffer cache for that user's queries. If 10 users are connected, there will be 10 dedicated server processes in the instance; if 500 users are connected, there will be 500 dedicated server processes, each one dedicated to getting the data into the SGA for its user. This means that every request is acted upon immediately, but it also means that additional memory and CPU overhead are associated with each server process. Each dedicated server process will likely spend most of its time sitting idle. This is the architecture decision made by most DBAs in shops where performance is pressed as critical and sufficient hardware resources are available to support it.

Shared Server

In a shared server architecture, there exists a pool of server processes running to support all the data retrieval requests for many users. Several connected users are directed to each shared server process. Oracle manages the user-to-server process utilization through the mechanism called Dispatcher. User processes are each assigned to a dispatcher in a one Dispatcher to many user processes configuration. There can be many Dispatchers in an instance, each servicing many user processes. The Dispatcher puts all the user requests for data into one queue (first in, first out). The shared server processes process the requests for data one at a time.

The shared server configuration can help you conserve memory and CPU usage on the machine that you have hosting the Oracle Server. It also helps to limit the amount of time that each server process spends idle.

Shared server architecture is often preferred when many users connect and disconnect from the database as is often the case in Internet databases supporting online stores.

SQL Work Areas

For large, long-running, complex queries (data warehouses or decision-support queries, for example), a big portion of the runtime area that they use is dedicated to work areas allocated by memory-intensive operators such as sort-based operators, hash joins, and bitmap merges or bitmap creation.

A sort operator uses a work area (more commonly called the sort area) to perform the in-memory sort of a set of rows.

Next, we look at processes. An Oracle instance contains several different categories and several different types of processes, and it is important that you understand them.


Process Architecture

A process is a mechanism at the operating system level whose purpose is to run a series of steps. Some operating systems use the terms task, job, or thread, but regardless of the name, they all perform a job through designated steps. Each process usually runs in its own memory area.

Oracle instances have two primary types of processes: user processes and Oracle processes. The following list describes these and other processes:

  • User processes These are created and maintained for the sole purpose of facilitating the running the software code of an application program or an Oracle tool (such as SQL*Plus or Oracle Enterprise Manager). User processes manage the communication with the server processes through the program interface but do not interact directly with the database.

  • Oracle processes These are invoked by other processes to perform the functions on behalf of the calling process. Several different Oracle processes are discussed in the following section.

  • Server processes Oracle creates these to handle requests from the connected user processes; it directly interacts with the Oracle Server. The server processes communicate with the user processes and interact with Oracle to carry out the requests made by the user processes. It can be shared or dedicated.

  • Dedicated server process The typical way that the user processes connect with the server processes in the instance is through a dedicated server process, or a one-to-one relationship between the user process and the server process.

  • Shared server process These processes have a many-to-one relationship between the user processes and the server processes that connect via a dispatcher.

The differences between shared server architecture and dedicated server architecture are covered in depth for the Performance Tuning exam.

Now let's look at those processes that Oracle manages on its own, the Oracle background processes.


Background Processes

When the instance starts, Oracle creates a set of background processes that consolidate through functions what would otherwise have to be handled by multiple Oracle programs, each running for each user process called. These processes perform I/O and monitor the other Oracle processes. The background processes created include Database Writer (DBWn), Log Writer (LGWR), Checkpoint (CKPT), System Monitor (SMON), Process Monitor (PMON), Archiver (ARCn), Recoverer (RECO), Job Queue processes (Jnnn), Dispatcher (Dnnn), Lock Manager Server (LMS), and Queue Monitor (QMNn).

Database Writer (DBWn)

Database Writer (a mandatory background process) writes all modified blocks from the database buffer cache out to the proper datafiles. The write occurs at the following conditions:

  • Checkpoint, normal or incremental

  • Dirty buffers threshold reached

  • No free buffers available for a process

  • Timeout occurs

  • RAC ping request

  • Tablespace (either normal or temporary) offline

  • Tablespace set to read-only

  • DROP TABLE command

  • truncate Table command

  • BEGIN BACKUP TABLESPACE command

Typically, one Database Writer process (DBW0) is sufficient to handle the demands of most systems; you can, however, configure additional Database Writer processes (DBW1 through DBW9 and DBWa through DBWj) to improve the write performance of a system that modifies data heavily. The initialization parameter (more on the initialization files and their parameters in Chapter 4, "Managing an Instance") that handles the allocation of the extra processes is DB_WRITER_PROCESSES, and the parameter entry that would set the number of Database Writer processes to 6, for example, follows:

DB_WRITER_PROCESSES=6

Oracle uses write-ahead logging, which means that database writer does not need to write out the data blocks as soon as a transaction commits. Database writer, instead, is designed to perform its batched writes, making the writing of changed data blocks highly efficient. Ordinarily, it writes out these changes only when there is more data to be read into the SGA and too few database buffers to hold it. The least recently used data is written out to the datafiles first.

Log Writer (LGWR)

The Log Writer process (a mandatory background process) writes redo log entries from the redo log buffer out to the online redo logs on disk. If your database has multiplexed redo logs, log writer writes the redo log entries to the entire group of online redo log files and commits only when all the redo has been written to disk. Log writer performs sequential writes to the redo log files under the following conditions:

  • Transaction commit

  • More than 1MB of changed records in the redo log buffer cache

  • Redo log buffer cache one-third full

  • Before database writer writes modified blocks out of the buffer cache

  • Every 3 seconds

Checkpoint (CKPT)

An event, a checkpoint, occurs when the Oracle background process DBW n is triggered by the CKPT process to write all the modified database buffers from the SGA out to the datafiles, including any committed or noncommitted data. This ensures that the data blocks in memory that change frequently are written out to files regularly. Because of the LRU algorithm of DBW n, a data block updated frequently may never age out because it never qualifies as a least recently used block. A checkpoint makes sure that this data gets written out. Because all the database changes up to the checkpoint have been recorded in datafiles, the redo log entries from before the checkpoint are no longer needed to be applied to the datafiles if an instance recovery is needed; therefore, checkpoints can expedite a media recovery situation. The checkpoint (a mandatory background process) ensures that the checkpoint number is written into the datafile headers andalong with the log sequence number, archive log names (if the database is in archive log mode), and the system change numbersis written into the control file.

CKPT does not write blocks to disk; DBWn always performs this task. CKPT triggers DBWR to write the blocks out to their respective files.

A checkpoint occurs whenever there is a log switch in the online redo log files or whenever either of the following two parameters' settings is met:

  • LOG_CHECKPOINT_INTERVAL Sets the checkpoint intervals to occur whenever a particular volume of data has been changed

  • LOG_CHECKPOINT_TIMEOUT Sets the checkpoint intervals to occur whenever a given period of time has elapsed

System Monitor (SMON)

The System Monitor process (a mandatory background process) performs instance recovery when a failed instance starts up again. In a Real Application Clusters environment, the SMON process of one of the instances can perform instance recovery for one or more other instances that may have failed. SMON recovers any terminated transactions that might have been skipped during recovery because of file-read errors or offline errors. These failed transactions are eventually recovered by SMON whenever the tablespace or file is brought back online. SMON is also responsible for coalescing free extents in any dictionary managed tablespaces so that the free space is contiguous and easier for Oracle to allocate if pctfree is set to a number greater than 0.

Process Monitor (PMON)

The Process Monitor (a mandatory background process) process performs process recovery when a user process fails (how's that for a bunch of processes!). PMON is responsible for cleaning up the cache and freeing resources that the failed process was using and for checking on the dispatcher and server processes and restarting them if they have failed. It cleans up after failed processes by doing the following:

  • Rolling back the user's current transaction

  • Releasing all currently held table or row level locks

  • Freeing any resources currently reserved by the user

  • Restarting dead dispatches

Archiver (ARCn)

Archiver (an optional process) copies the online redo log files to archival storage after a log switch has occurred for databases running in archive log mode. Although a single archiver process (ARC0) is usually sufficient for most systems, you can specify up to 10 ARC n processes by using the dynamic initialization parameter LOG_ARCHIVE_MAX_PROCESSES. If the archiving workload gets to be too much for the current number of archiver processes, log writer automatically starts another archiver process up to the maximum of 10 processes. ARC n is active only when a database is in ARCHIVELOG mode and automatic archiving is enabled.

Recoverer (RECO)

The Recoverer (an optional process) is used to resolve any distributed transactions left pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to the associated remote databases and, if it is successful, automatically complete the commit or rollback of the local portions of any pending distributed transactions.

Job Queue Processes (Jnnn)

Job Queue processes (an optional process) are used for automating batch processing and are managed dynamically. This enables job queue clients to use more or fewer job queue processes when required. The resources used by any new processes spawned are released when they are idle. It is important to note, however, that you need to be using the DBMS_JOB functionalities for the Job Queue processes to accomplish anything, regardless of to what the initialization parameters are set.

The initialization parameter relevant to the Job Queue processes is the JOB_QUEUE_PROCESSES parameter. This parameter allows you to set, as a numeric, the number of Job Queue processes that you want to have available to run on your instance. The default value is 0.

To get information on the Job Queue processes in the database, you would query the Data Dictionary views listed in Table 1.2. Table 1.2 provides information on the relevant view and the information you can find there.

Table 1.2. Job Queue Process Data Dictionary Views

Data Dictionary View

Description of Information Available

DBA_JOBS

This view lists all the jobs in the database.

USER_JOBS

This view lists all the jobs owned by the user who is logged in.

DBA_JOBS_RUNNING

Lists all jobs in the database that are currently running. This view can be joined with V$LOCK to identify jobs that have locks.

Dispatcher (Dnnn)

Dispatcher is an optional background process present only when a shared server configuration is used. At least one Dispatcher process is created for every communication protocol in use. Each dispatcher process is responsible for routing requests from a connected user process to an available shared server process and returning the responses back to the appropriate user process.

Lock Manager Server (LMS)

The Lock Manager Server process (an optional process) is used for inter-instance locking in Real Application Clusters.

Queue Monitor (QMNn)

Queue Monitor processes are also optional background processes responsible for monitoring the message queues for Oracle Advanced Queuing. You can configure up to 10 queue monitor processes.

Now that you have some idea about what constitutes the instance and the database, lets look at connecting to the instance.


Connecting to an Instance

Before a user can submit a SQL statement to an Oracle database, he must connect to an instance. The user starts a front-end tool, such as SQL*Plus, an alternative such as SQL Navigator or Toad, or runs an application developed to assist with database interaction.

Typically, the user connects and logs on to the Oracle Server. When this happens, a server process is created on the server running the Oracle Server.

This process is responsible for communicating with the Oracle instance on behalf of the user process running on the workstation or the client and for execution of the SQL statements on behalf of the user.

Connection

The connection is a communication pathway between the user process and the Oracle Server. This connection can take three distinct forms:

  • A user can log on to the base operating system on which is running the Oracle instance. When logged in, the user then starts a tool (again, SQL*Plus or an application designed for the purpose). The communication channel is created using interprocess communication systems resident on the operating system (TCP/IP, for example).

  • A user can launch a tool on her local computer workstation and connect over a network to the server on which the Oracle instance is running. This is the typical client/server configuration, and network software is the communication vehicle on which the transactions travel.

  • There can be a three-tiered connection, where the user's computer communicates via a network connection with an application resident on an application server or other network server. This middle tier server then communicates via another network connection to the database server running the Oracle instance. This is known as a dedicated server connection.

Alternatively, users can connect in a shared server configuration where multiple user processes connect to a single shared server process.

A database server configured to allow multiple user processes to share few server processes is known as a shared server configuration. In this configuration, a user process connects to the dispatcher process (D nnn) whose job is to direct the requests to a queue from which an idle shared server process picks its requests. The request and response queues, as well as other parts found in the PGA in a dedicated server configuration, are found in the SGA when the server is a shared server.

In a shared server environment, the User Global Area (UGA) cannot be stored in the Process Global Area (PGA) because much of the processing is in a dedicated server environment; the UGA is found in the SGA.

Session

A session is considered to be each specific connection of a user to an Oracle Server. It starts as soon as the user is authenticated to the instance and ends either when the user logs off or when there is an abnormal termination of the interface through which the user is connected. Depending on the configuration of the interface through which the user is connecting (for example Oracle E-Business Suite) there can be many concurrent connections possible for the same user ID.

Only the database administrator to perform certain maintenance jobs and either the database administrator (the sysdba role) or the sysoper role to start and/or stop the instance can log in to the instance when it is not up and open for general use.


Exam Prep Questions

1:

Which statement about an Oracle instance is true?

  • A. The data dictionary cache is not part of the shared memory area of an Oracle instance.

  • B. Multiple instances and therefore multiple databases can execute on the same computer.

  • C. The Oracle Server is a combination of memory structures, background processes, and external files.

  • D. Database writer writes the redo logs from the redo log buffer to the redo log files.

A1:

Answer B is correct. It is possible, and often the case, to have multiple instances running on a single computer, each accessing its own physical database. Answer A is incorrect because the data dictionary cache is part of the shared memory area, or the SGA, of an Oracle instance. Answer C is incorrect because an Oracle Server is the combination of the Oracle database and the Oracle instance. Answer D is incorrect because database writer writes the dirty data buffers out to the datafiles and log writer writes the redo logs from the redo log buffer to the redo log files.

2:

Which of the following is responsible for writing data blocks from the database buffer cache out to the datafiles?

  • A. DBWn

  • B. RECO

  • C. ARCn

  • D. Jnnn

A2:

Answer A is correct. Database Writer is responsible for writing data from the database buffer cache out to the datafiles. Answer B is incorrect because Recoverer is responsible for resolving transactions left pending due to a network or system failure. Answer C is incorrect because Archiver writes the active redo log files to archive log files when there is a log switch. Answer D is incorrect because the job queue process assists with automating batch job processes.

3:

Which tablespace is the minimum required when creating a new database?

  • A. Undo tablespace

  • B. Temporary tablespace

  • C. System tablespace

  • D. Users tablespace

A3:

Answer C is correct; the minimum necessary tablespace for the creation of a database is the system tablespace. Answer A is incorrect because, although an undo tablespace is necessary for implementation of automatic undo, it is not necessary for the creation of the database. Answer B is incorrect because although a temporary tablespace is a good idea at creation time and for use by users, it is not necessary for creation. Answer D is incorrect because a user's tablespace isn't necessary.

4:

Which three types of files are parts of an Oracle database? [Choose three]

  • A. Control file

  • B. Archive log file

  • C. Redo log files

  • D. Parameter files

  • E. Datafiles

A4:

Answers A, C, and E are correct. Control files hold entries that specify the physical structure of the database, redo log files hold a record of all changes made to any data in the database, and datafiles hold the user data stored in the database. Answer B is incorrect because the Archive log files are used in backup and recovery and are written to by log writer when there is a log switch, but they are external files to the database. Answer D is incorrect because parameter files hold information that Oracle uses when it starts up, but they are not considered a part of the database.

5:

From smallest to largest, rank the following logical pieces of the database: data block, tablespace, extent, segment.

  • A. Tablespace, segment, extent, data block

  • B. Data block, segment, extent, tablespace

  • C. Segment, extent, data block, tablespace

  • D. Data block, extent, segment, tablespace

A5:

Answer D is correct: data blocks make up extents; extents make up segments; and segments make up tablespaces. Answer A is incorrect because it is from largest to smallest. Answer B is incorrect because segments don't make up extents. Answer C is largest to smallest except for tablespace, which is in the wrong place.

6:

Which two statements about storage structures in the Oracle database are true? [Choose two]

  • A. A data block is a logical structure.

  • B. One file can belong to more than one tablespace.

  • C. An extent can belong to more than one tablespace.

  • D. A tablespace can contain more than one datafile.

  • E. A data block can belong to multiple datafiles.

  • F. An extent can be made up of more than one segment.

A6:

Correct answers are A and D. A data block is a logical structure, and a tablespace is often made up of more than one datafile. Answer B is incorrect because a datafile can belong to only one tablespace. Answer C is incorrect because an extent can be a part of only one tablespace. Answer E is incorrect because, although a data block can be multiple operating system blocks, they must all belong to the same datafile. Answer F is incorrect because segments are made up of extents (one or many), but extents are not made up of segments.

7:

When is the SGA created in an Oracle instance?

  • A. the database is created.

  • B. When the instance is opened.

  • C. When the user process is started.

  • D. When a server process is started.

A7:

Answer B is correct. The SGA, as part of the memory structure, is created when the instance is started and remains allocated until the instance is shut down. Answer A is incorrect because the SGA isn't part of the database. Answer C in incorrect because user processes have to interact with an open instance, and the SGA, as a memory structure, opens when the instance opens. Answer D is incorrect, because, as a memory structure, the SGA has to be available before any server processes can start.

8:

When is the PGA created in an Oracle instance?

  • A. When the instance is created.

  • B. When the database is mounted.

  • C. When a single user logs directly into the database.

  • D. When a server process is started.

A8:

Answer D is correct. The PGA gets created to support a server process and, therefore, gets created when that server process is started. Answer A is incorrect because if no server processes are running, the PGA is not necessary. Answer B is incorrect because when the database is mounted no server processes are available to start the PGA. Answer C is incorrect because the PGA supports server processes, not user processes.

9:

Which statement is true about segments?

  • A. Each table has its own segment.

  • B. A segment is created every time an extent is created, extended, or altered.

  • C. An index segment is created every time a table is created.

  • D. A segment is deleted whenever a table is truncated.

A9:

Answer A is correct. Each table, index, or other database object has its own segment. Answer B is incorrect because a segment is made up of multiple extents. Answer C is incorrect because index segments are created for indexes, and table segments are created for tables. Answer D in incorrect because the only time a segment is deleted is when the object that they are created on is dropped or truncated with either the REUSE STORAGE or DROP STORAGE parameters included.

10:

At what point does the CKPT process write data blocks to the datafiles? [Select all that apply]

  • A. Whenever LOG_CHECKPOINT_INTERVAL parameter tells it to.

  • B. Whenever LOG_CHECKPOINT_TIMEOUT tells it to.

  • C. Whenever there is a log switch.

  • D. CKPT doesn't write anything out to files; it tells the other processes to do that.

A10:

Answer D is the only correct answer. Checkpoint doesn't actually write anything out to files; it causes the DBW n process to write the data from the database buffer cache out to the database files. Answer A is incorrect because LOG_CHECKPOINT_INTERVAL tells CKPT how often in terms of volume to cause a checkpoint, but it does not ever write anything. Answer B is incorrect because LOG_CHECKPOINT_TIMEOUT tells CKPT how often in terms of periods of time in seconds to cause a checkpoint, but it does not ever write anything. Answer C is incorrect because a log switch causes CKPT to occur, but it does not ever write anything.


Need to Know More?

The concepts manual, available through http://otn.oracle.com/pls/db92/db92.docindex?remark=homepage is a good source for information on the Oracle architecture.


Chapter 2. Getting Started with the Oracle Server

Terms you'll need to understand:

  • Oracle Universal Installer

  • Optimal Flexible Architecture

  • Password file

Concepts you'll need to master:

  • Identify command database administration tools.

  • Identify features of Oracle Universal Installer.

  • Understand the benefits of Optimal Flexible Architecture.

  • Set up and use password file authentication.

  • List Oracle Enterprise Manager components and their uses.

Oracle provides many tools and utilities to assist you in your job as database administrator (DBA). In this chapter, we will look at these tools and utilities.


Administrative Tools

Oracle provides many tools to assist both DBAs and developers with accomplishing their jobs in a more effective and efficient manner. Several tools can be used to help you maintain your databases. The tools covered by the exam will be covered in this book. Table 2.1 provides the list of tools that will be covered and a brief description of each.

Table 2.1. Oracle Provided Management Tools

Tool

Description

Oracle Universal Installer (OUI)

Java-based graphical user interface used to assist with the installation, upgrade, and removal of Oracle software components.

Oracle Database Configuration Assistant

Java-based graphical user interface that can either interact with OUI or be run independently. Used to create, delete, or modify a database.

Password File Utility

Utility for creating a database password file.

SQL*Plus

Utility used to access data in an Oracle database, alter structures, and perform maintenance.

Oracle Enterprise Manager (OEM)

Graphical user interface used to administer, monitor, tune, and troubleshoot single or multiple databases.


Oracle Universal Installer (OUI)

Oracle Universal Installer (OUI) is a Java-based utility used to install, upgrade, and remove Oracle software components. It can also be used to create a database. OUI can assist you with potentially daunting tasks, including the following:

  • Automatic detection and resolution of component interdependencies

  • Remote, web-based installations

  • Inventory of installed components; the machines on which they are installed; and the products, names, and versions installed on them

  • Tracking of suite installations

  • Installation of multiple or individual components

  • Deinstallation of any or all components

  • Support of multiple Oracle homes

  • Support and configuration for globalization technology

  • Automatic detection of the language of the operating system and use of that language in which to run the installation session

  • Ability to run in either interactive mode or silent mode (by use of a response file)

Although OUI offers installation solutions only to Java-enabled platforms, it allows those platforms to enjoy a common installation format and user experience unrelated to the platform on which the database is to be installed.

The following sections describe the two ways in which you can run OUI: interactive and noninteractive. The installer works in the same way regardless of the mode of operation. The difference is in where it gets its answers.

OUI Interactive

Typically, OUI is run in an interactive mode with the user running the installation providing the input for the interface as the prompts require. This is known as interactive mode installation.

To start the OUI interface on Unix, run the following command:

./runInstaller

It is important to know that, to run the Universal Installer in this manner, you have to be running either Xwindows or an xterm terminal session so that the Java front-end will launch correctly and you will be able to run the installer.

On Windows, you need to run the following, either at a command prompt or from the Start/Run menu:

C:\program files\oracle\oui\install> setup.exe

This is true for those places where the installer has already been installed on the system. Ordinarily, on a Windows platform, you would likely simply run it from the CD-ROM drive.

Remember, you never run the ./runInstaller command while logged in to Unix as the root user.

Operating system-specific Oracle documentation can be used to gain information on installing Oracle on any given supported platform.

OUI Noninteractive

Noninteractive installations are done whenever no user action is intended, or if no graphical terminals are available for the installation. The installation parameters are customized using a response file. Response files are text files that contain variables and associated values used by the installer during the installation process. For example, ORACLE_HOME will be one of the variables set in the response file, as will the installation type (Typical or Custom).

When using the response file in the noninteractive installation mode, you first need to edit the response file to specify the components that you want to install. Templates for the response file are available in the stage/response directory on Unix platforms. You need to copy one of these response files and modify the copy to match your environment.

It is important to remember that noninteractive is not character mode. Noninteractive provides no feedback whatsoever. Character mode is an installation running as text only with no graphical user interface.

To run OUI in noninteractive mode using response files, run the following command in Unix:

./runInstaller responsefile myresponsefile silent

To run the same command in Windows, run the following at the command prompt:

C:\program files\oracle\oui\install> setup.exe -silent -nowelcome -responseFile filename

In this example, -silent means that it will be a noninteractive installation. -nowelcome means that you don't want to see the welcome screen, and responseFile filename provides to the setup program the name and location of the response file in which you have provided your responses to the installer's questions.

You can also opt to use OUI to install the Oracle software into multiple Oracle homes. The following section describes this process.

Multiple Oracle Homes

The OUI assists you with the installation of software into several active Oracle homes on the same physical machine. Oracle home is the set of software files under which a set of Oracle installed products runs. This Oracle home consists of the directory location where the product or products are installed, the associated system path for that product or products, and the services that are running associated with a given set of system software files.

The OUI allows you to install into several active Oracle homes on the same machine. This is possible and practical as long as the products you are installing and planning on working with support multiple Oracle homes at runtime. Until Oracle 9i, it was not simple to run multiple Oracle homes on a Windows platform. You can have multiple versions of the same product each in its own Oracle home, or you can have different products running from different Oracle homes concurrently. Products that have been installed in a single Oracle home will not conflict with or interact with any of those products installed in any other Oracle home.

This means that you can update the software in any home at any time independently of any other Oracle home on the same machine, assuming that all Oracle products and processes installed in the target home are shut down. Processes spawned for products installed in other Oracle homes can remain running throughout the installation, safely, without fear of corruption.

The Oracle home currently being accessed by the OUI for the purpose of installation or deinstallation of products is known as the target home. To upgrade products, install additional products into an existing home, or remove products from the target homes, those products must be shut down and stopped.

Creating an Oracle Home

To create an Oracle home, follow these steps:

1.
Run the OUI. Figure 2.1 shows the initial installer screen.

Figure 2.1. Oracle Universal Installer Welcome screen.

2.
In the File Locations page shown in Figure 2.2, enter the Oracle home settings for the installation session under Destination.

Figure 2.2. Oracle home File Locations screen.

There are onlytwo fields in the Destination section of the File Locations screen: Name and Path. (The Name field appears only on Windows platforms.)

On Windows platforms, Oracle homes are identified by name. The Oracle home name identifies the program group associated with a particular Oracle home and those Oracle services installed in the associated home. The Oracle home name must be 1 to 16 characters long and can only include alphanumeric characters and underscores.

The Path field is the Oracle home and its full path. You can either enter the path where you want the Oracle home to be located, or select an Oracle home from a drop-down list of existing Oracle homes. The Oracle home location is the directory where you want the products to be installed.

Listing the Oracle homes on Windows platforms provides

  • All Oracle homes already created using the OUI

  • All Oracle homes created using the previous versions of the Oracle Installer

  • The Oracle home to which the ORACLE_HOME environment variable points

Listing the Oracle homes on Unix provides

  • All Oracle homes already created using the OUI

  • All Oracle homes defined in the /var/opt/oratab file

  • The Oracle home to which the ORACLE_HOME environment variable points

On Oracle, it is possible for all Oracle homes to share a common ORACLE_BASE. This is, however, not true on Unix.

If no Oracle homes exist that meet any of these criteria, OUI calculates a default Oracle home based on the disk with the largest amount of free space or the one named most logically to the installer. It is wise to know ahead of time where you want the binary files installed so that you can easily tell the installer when it is wrong.

Data files for any databases that may be installed with the installer (for example, when installing Oracle E-Business Suite) may be installed within an Oracle home but can be redirected as you choose. Use the Browse button to choose the directory into which to install the given product.

On Windows platforms, this must be a valid path that is not found within the Windows or Winnt directory.

Different Oracle homes cannot share the same base location, so you need a different path for each Oracle home.


Oracle Database Configuration Assistant (DBCA)

The Oracle Database Configuration Assistant (DBCA) can be run through the OUI, thereby allowing you to create a database at the same time you are installing the binaries.

In Chapter 3, "Creating a Database," we will discuss DBCA at length, but in connection with the OUI, understand that DBCA can be called, depending on how you choose to run the install. For example, you can choose to create your initial database after the binaries have been installed.


Optimal Flexible Architecture (OFA)

Oracle's Optimal Flexible Architecture (OFA) is the Oracle recommended, standard database layout. OFA includes three primary objectives:

  • OFA establishes a directory structure into which any database file can be stored. This can facilitate use of any disk resource.

  • OFA separates objects with different behaviors into different tablespaces.

  • OFA maximizes database reliability, availability, and performance by separating database components across different disk resources.

The OFA directory structure is a standard set of configuration guidelines that allow for fast, reliable Oracle databases that require the minimum maintenance.

OFA is designed to assist you, as a DBA, to do the following:

  • Organize a large amount of complicated software with multiple components and products.

  • Organize data and control structures on disk in such a way as to avoid device bottlenecks and poor performance.

  • Facilitate routine administrative tasks that are often vulnerable to data corruption.

  • Adequately manage and administer database growth.

  • Help minimize fragmentation of free space in the data dictionary, isolate what fragmentation might occur, and minimize resource contention.

OFA installation is supported on all platforms on which Oracle can be installed and helps you organize your database files by type of file and by usage. Binaries, data files, and supporting files can be spread across several disks, and because of naming conventions, each can easily be differentiated from the rest. Database files can easily be determined to be different from log and control files, redo log files, and trace files. Because of OFA, it is more simple and elegant to administer multiple Oracle homes on the same machine because files can be spread over multiple disks and directories. Not only is this more efficient administratively, it also means that better performance can be achieved by decreasing disk contention among the different types of files.

The directory structures in Table 2.2 show examples of what might be found in an OFA-compliant installation in both Windows and Unix environments.

Table 2.2. Example OFA Directory Structures

Unix Software

Windows Software

Oracle_base
/product
/release number
/bin
/dbs
/rdbms
/
/admin
/instance name
/adhoc
/adump
/bdump
/cdump
/create
/exp
/pfile
/udump

ORACLE_HOME
\product_release
\bin
\dbs
\rdbms
\...
\admin
\instance name
\adhoc
\adump
\bdump
\cdump
\create
\exp
\pfile
\udump

Files

Files

/oracle
/oradata
/ dbname
redo01a.log
redo02a.log
redo03a.log
control03.ctl
/oracle2
/oradata
/dbname
control01.ctl
index01.dbf
undo01.dbf
system01.dbf
temp01.dbf
users01.dbf
redo01b.log
redo02b.log
redo03b.log
/oracle3

/oradata
/ dbname
control02.ctl
redo01c.log
redo02c.log
redo03c.log

F:\oracle
\oradata
\prod
redo01a.log
redo02a.log
redo03a.log
control03.ctl
G:\oracle
\oradata
\prod
control01.ctl
indx01.dbf
undo01.dbf
system01.dbf
temp01.dbf
users01.dbf
redo01b.log
redo02b.log
redo03b.log
H:\oracle
\oradata
\prod
control02.ctl
redo01c.log
redo02c.log
redo03c.log

It is important, when installing with OFA in mind, that you organize the file system so that you can more easily administer growth by adding data into existing databases, adding users, and creating new databases. What's more, you need to consider the ramifications of later adding hardware so that you can easily and elegantly distribute the I/O load across all available drives and devices.

Your database's security is vital, and regardless of what interface you use to access your databases, authentication is uppermost in the minds of most DBAs. The following section deals with Oracle 9i's capability to address many of these security concerns.


Password File Authentication

Recall that when a database is created, the users SYS and SYSTEM are created automatically and are granted the DBA role. This is to enable you to administer the database from the beginning of its creation and to allow you the ability to create more users and roles as your needs require. If you create a pre-seeded database, you also get the SCOTT schema in which you or your developers can play without adversely impacting your company's data. The default passwords are well known and well documented, and Oracle strongly suggests that you change the default passwords (at least to SYS and SYSTEM, if not to SCOTT), but they also leave the onus on the DBA to change them. Unfortunately, this does not always happen.

When newly installed, the default password for SYS is change_on_install (I personally think that they make this password particularly long so that you really want to change it), and the default password for SYSTEM is manager. SYS is the owner of the database and the data dictionary. SYSTEM is the owner of all other internal tables and all views used by the Oracle tools.

Oracle has begun to address this security risk in Oracle 9i by locking and expiring many of the default accounts and by starting to eliminate the default passwords.

Locked and Expired Default Accounts

Depending on how you created your database, you may have had it installed with a couple to several default accounts. If you created the database with the DBCA, all default accounts, with the exception of the SYS, SYSTEM, and SCOTT schemas, are locked and expired. This forces the DBA to deliberately unlock and unexpire the accounts before they can be used. This adds to the security of your database because many of these accounts have significant privileges but rarely, if ever, need to be accessed by anything other than Oracle itself.

Elimination of Default Passwords

Another step that Oracle took, in Oracle 9i, is to force the DBA installing the database to provide the passwords for SYS and SYSTEM when the database is created through the DBCA. Although this forces you to take one extra step when creating the database, it also makes your database more secure after it has been created.

The passwords still take on the default values when the database is created manually.

You can further secure your database by using password files to ensure that those accessing the database as SYSDBA or SYSOPER do so with fully granted authority.

Password File

Another way to help to secure your database is to use a password file. There are two ways to authenticate users to the database. One way is to use OS authentication and put the responsibility on the operating system to make sure that users logging in are the correct users and that they have the appropriate privileges. The other way is to use a password file.

Oracle provides a password utility (called orapwd) that helps the DBA to create a password file. This file holds the connection information relevant to users who have been granted the SYSOPER or SYSDBA role. Users logging in as SYSDBA will connect to the SYS schema, not their own. Those logging in as SYSOPER are connected, simply, to the PUBLIC schema (see Chapter 17, "Managing Privileges").

Password authentication for SYSOPER and SYSDBA users requires the use of a password file. To create this file, enter the following command:

orapwd file=filename password=password entries=max_num_users

filename is the name of the password file.

password is the password for either the SYSOPER or the SYSDBA.

entries is the maximum number of distinct users who can be allowed to connect either as SYSDBA or as SYSOPER. If the number is exceeded, you need to create a new password file to accommodate the additional users. It is safer to double (or more) the number that you ever think you will need; people will quit, people will be hired, the needs will expand, and you will soon find that you have exhausted the number of users that you allotted.

After the password file has been created, you need to set the REMOTE_LOGIN_PASSWORDFILE parameter to either EXCLUSIVE or SHARED. EXCLUSIVE indicates that only the given instance can use the password file in question and that the file in question contains usernames other than SYS. EXCLUSIVE allows you to grant either SYSDBA or SYSOPER to individual users, allowing those users to connect using their own usernames and passwords, adding to security and traceability. SHARED indicates that you are allowing more than one instance to use the password file. The only user who can be added to a SHARED password file is SYS.

After you have set the REMOTE_LOGIN_PASSWORDFILE and created the password file, you need to connect to the database as the SYS user and grant relevant and appropriate users the privileges required by your business rules.

You can delete the existing password file and create a new password file as necessary by simply rerunning the password utility.

There are several Oracle provided interfaces through which you can interact and maintain your database. The following section looks at these interfaces.


DBA Tools

There is no one right way to do your job. As a DBA, you need to be flexible and able to use as many of these tools to do your job as you can because different positions require use of different interfaces.

SQL*Plus

Oracle has provided SQL*Plus as a tool that allows users, developers, and DBAs to connect to, interact with, and manipulate the database. SQL*Plus provides a command-line interface through which you can provide commands to the database.

SQL*Plus provides the capability to start up and shut down the database, run and create queries, add or delete rows in tables, modify data that exists in tables, and write custom text reports drawing data out of the database using a subset of the ANSI standard SQL with the addition of specific (PL/SQL) additions.

SQL*Plus runs natively on whatever platform you have your database installed on and can be run as a client application, connecting to the database remotely.

Figure 2.3 shows an example of SQL*Plus running in a Unix environment natively, and Figure 2.4 shows a Windows version of SQL*Plus connecting to a database, regardless of where the database is running.

Figure 2.3. SQL*Plus in a Unix environment.

Figure 2.4. SQL*Plus in the Windows environment.

But SQL*Plus isn't the only Oracle provided tool that you can use to help administer your database. Oracle Enterprise Manager (OEM) is a fully functional graphical user interface into the database that can assist you with many of your complex day-to-day database tasks.

iSQL*Plus is a browser-based implementation of the SQL*Plus interface. iSQL*Plus can be used to connect a user to an Oracle database over the Internet to perform the same tasks that can be performed through the traditional SQL*Plus command-line interface. Although the interface is supported only in the Windows platform at this time, iSQL*Plus allows users to use a Web browser as their interface through which it makes use of an Oracle HTTP Server with the iSQL*Plus Server add-on to access an Oracle database.

Oracle 9i provides iSQL*Plus only on Windows platforms.

Oracle Enterprise Manager (OEM)

OEM serves as a graphical centralized systems management console primarily for the use of the DBA. It provides a common set of services that help to manage the Oracle environment, including integrated applications. It can manage not only your databases but also web servers and the listeners associated with both. Through OEM you can administer, diagnose, and tune multiple databases across multiple servers, including parallel servers and replicated databases, from one central location.

OEM's unified management framework is a Java-based console that encompasses a suite of tools and services, a network of servers and intelligent agents. It can provide both a hierarchical tree view of the overall system and a graphical representation of the objects and their relationships in the system.

Through OEM, you can use the following components simply and elegantly:

  • Instance Manager performs startup, shutdown, and monitoring of the database. Figure 2.5 shows an example of what can be found in the Instance Manager.

    Figure 2.5. Instance Manager.

    [View full size image]

  • Security Manager allows you to manage users and their privileges and roles. Figure 2.6 shows an example of what can be found in the Security Manager.

    Figure 2.6. Security Manager.

    [View full size image]

  • Storage Manager assists you in maintaining tablespaces, data files, rollback segments, and redo log groups. Figure 2.7 shows an example of what can be found in the Storage Manager.

    Figure 2.7. Storage Manager.

    [View full size image]

  • Schema Manager helps you to create and manage objects such as tables, indexes, clusters, views, synonyms, stored procedures, and other program units. Figure 2.8 shows an example of what can be found in Schema Manager.

    Figure 2.8. Schema Manager.

    [View full size image]

  • SQL*Plus Worksheet provides the capability to issue SQL statements against any database. Figure 2.9 shows the SQL*Plus Worksheet interface.

    Figure 2.9. SQL*Plus Worksheet.

    [View full size image]

Two additional subcomponents allow you to perform hands-off monitoring and maintenance of the database. These are the Job Scheduling System and the Event Management System and are discussed in the following sections.

Job Scheduling System

The Job Scheduling System allows you to schedule and manage any job tasks that an administrator can perform through the operating system locally or with SQL scripts and perform this administration across the network, even remotely across an intranet.

With the Job Scheduling System, you can perform tasks on multiple databases or other managed nodes without having to maintain active connections to all targets, and what's more, the scheduled jobs can run simultaneously on different nodes in the system without your even having to be there to launch or monitor them.

The three tiers of OEMConsole, Oracle Management Server, and Intelligent Agentsrunning on the managed nodes, all work together to schedule and execute the desired jobs.

Event Management System

The Event Management System allows you to efficiently monitor a large system even from remote locations. Using the Event Management System together with Intelligent Agent monitored managed nodes, you can effectively monitor any number of databases, nodes, or other targets 24 hours a day. You can have the system alert you whenever a problem arises or a specific condition is detected, or you can have the system take its own action (for example adding another 25MB to a tablespace if the tablespace approaches the point of running out of space). You can pinpoint only the targets you want to monitor or monitor the overall system.

Events are, simply, a group of tests that you want to have routinely run on your managed systems. OEM includes a wide variety of predefined tests that you can use when creating your own events. The event tests are grouped by target type, for instance:

  • Databases

  • Listeners

  • HTTP servers

  • Concurrent managers in Oracle E-Business Suite

  • Nodes

You can create your own custom events using the predefined event tests that have been installed with OEM as the basis. Your custom events are created with information that you enter in the Event property sheet of the Event Management System. You determine the parameters necessary for the events that you are definingparameters such as the target being monitored, the specific tests that you want to have the Event Management System perform, the frequency that you want to have the event test executed, and whether other administrators can share the events and which administrators should be notified if the event condition is met. Some of the predefined event tests have their own parameters with threshold values that you can customize for your system.

As a part of the management server, you can create an Oracle Management Server (OMS) repository. Within this repository will reside all the relevant information that will allow jobs to run and that will allow actions to be taken based on those jobs and their outcomes.

OMS Repository

The repository is a set of tables that gets created when you set up OMS. OMS uses this repository as its persistent back-end data store. It can be configured to allow for historical trending and so that more than one OMS can share a repository to provide fault tolerance to the system and ensure the accessibility and reliability of the OEM interface to the system.

OEM allows you to perform both routine and advanced administrative tasks and to automate those that meet your own defined criteria. Optional add-on packs are available that can allow you to perform even more tasks. These add-ons include the Diagnostic Pack, Tuning Pack, Change Management Pack, and Oracle Applications Manager (designed primarily for Oracle E-Business Suite).

OEM is based on a highly scalable three-tier model architecture and consists of the components discussed in the following sections.

OEM Console

The first tier of the system is comprised of the client consoles and management applications that provide the graphical interface to the administrators for all relevant tasks. This tier can either be a standalone front-end through which the maintenance tasks are performed, or a web interface through which the DBA can maintain the database. This first tier depends on the second tier, the Oracle Management Server, for the bulk of its application logic.

The Console is the central launching point for all applications. It can be run in either thin client (through a web browser) or fat client (locally installed client Console files) mode and can be launched either as standalone or through the Oracle Management Server.

Through this central interface, you can access Instance Manager, Schema Manager, Storage Manager, and SQL*Plus Worksheet.

You can launch the Console either by entering the following at the command line

oemapp console

or by selecting Start, Programs, Oracle Enterprise Manager Console.

At the Login dialog box (see Figure 2.10), you can determine whether you want to run the application in standalone mode or from the OMS service.

Figure 2.10. OEM Login dialog box.

For the purpose of the exam, it generally is assumed that you will be running standalone.

After you are logged in, you can add databases to the database tree and start maintaining that database. To do this, you need to select Add Database to Tree from the Navigator menu and enter the values for Hostname, SID, Port Number, and Net Service Name of the desired database.

Now that you have a database, you can expand this working database from the Database folder, right-click the working database, and select Connect. Enter the username, password, and service name for the given database and click OK.

The Add Database to Tree dialog box appears automatically when you launch the Console in standalone mode the first time. It assumes that you want to monitor or maintain a database when you launch the Console, and, because it doesn't have one already discovered, it is waiting for you to tell it where you want it to go.

Oracle Management Server (OMS)

The OMS tier is the core of the OEM framework. It provides the administrative user accounts, processes the functions (jobs and evens), and manages the distribution of information between the first and third tier (the managed nodes).

OMS uses a repository schema (either in its own database or in a schema in an existing database) to store all system data, all application data, information about all managed nodes, and information concerning any add-on packs that you might have purchased and are running.

Managed Nodes

The third tier, the managed nodes, contains the targets for the management server. These targets can be databases or any other managed service.

Residing on each node has to be an Oracle Intelligent Agent, which communicates with the OMS and performs tasks on the managed services sent by the consoles and the client management applications. Only one Intelligent Agent is required per node, regardless of how many services and databases are managed on that node.

The Intelligent Agent functions totally independently from the databases and independently from the Console and Management Servers. This independence allows the Intelligent Agent to perform tasks such as starting up and shutting down the database and remaining operational if any part of the system becomes unavailable for any reason. This also allows the Intelligent Agents the capability to alert the responsible people when problems exist in the system that make the services unavailable.


Exam Prep Questions

1:

Through what Windows-only, browser-based interface would you enter SQL statements to retrieve information from the database?

  • A. SQL*Plus

  • B. OEM

  • C. SQL Worksheet

  • D. iSQL*Plus

A1:

Answer D is correct; iSQL*Plus is the Windows browser-based interface that you use to access or manipulate data in the database. Answer A is incorrect; SQL*Plus is a command-line interface but is not browser based. Answer B is incorrect; OEM itself provides a command-line interface but is not only on Windows. Answer C is incorrect; SQL Worksheet is the interface presented through OEM but is not a Windows-only interface.

2:

What is one thing that you cannot do through the OEM interface?

  • A. Start a database

  • B. Create users

  • C. Delete roles

  • D. Create tablespaces

  • E. Create a database

A2:

Answer E is correct; the only thing listed that you cannot do through the OEM interface is create a new database. Answers A, B, C, and D are all incorrect because you can create all these things through the OEM interface.

3:

What utility do you run to create the password file?

  • A. runInstaller

  • B. orapwd

  • C. OEM

  • D. iSQL*Plus

A3:

Answer B is correct; running orapwd creates the password file. Answer A is incorrect; runInstaller runs the Java-based installation interface. Answer C is incorrect; OEM offers no direct way to create a password file. Answer D is incorrect; iSQL*Plus is a command-line interface, not a password creation utility.

4:

What is Oracle's Java-based installation utility?

  • A. runInstaller

  • B. Oracle Installer

  • C. Oracle Universal Installer (OUI)

  • D. Oracle Enterprise Manager (OEM)

A4:

Answer C is correct; the name of the Java-based utility used to install the Oracle software is the Oracle Universal Installer. Answer A is incorrect; runInstaller is the command used in Unix to launch the OUI. Answer B is incorrect; it is referred to as Oracle Universal Installer because it is universally employed across any Java-enabled platform. Answer D is incorrect; you do not use the OEM utility to install the software.

5:

Users with what roles can be governed by the password file? [select all that apply]

  • A. DBA

  • B. SYSDBA

  • C. SYSTEM

  • D. SYSOPER

  • E. PUBLIC

A5:

Answers B and D are correct; the password file can be used to govern the access to the database by those who have been defined with the role of SYSDBA or SYSOPER. Answer A is incorrect; DBA role information is not stored in the password file. Answer C is incorrect; SYSTEM is a userid not a role. Answer E is incorrect; PUBLIC is not a role governed in the password file.

6:

What is the difference between interactive and noninteractive mode of the OUI? [select all that apply]

  • A. OUI runs in character mode in noninteractive.

  • B. Interactive mode means that you deliberately answer questions interactively.

  • C. Interactive mode is character mode.

  • D. Noninteractive mode uses a response file.

A6:

Answers B and D are correct; interactive means that you actively answer questions as you go, and noninteractive means that you have those answers in a response file. Answers A and C are incorrect; neither interactive nor noninteractive modes means that the installer will be running in character mode.

7:

What utility is used to create and configure databases? [select all that apply]

  • A. OEM

  • B. OUI

  • C. DBCA

  • D. OMS

A7:

Answers B and C are correct; DBCA (Database Configuration Assistant) is used to create and configure databases, and OUI calls DBCA if you choose to create an initial database as an installation choice. Answer A is incorrect; OEM does not allow you to create a new database. Answer D is incorrect; OMS is a component of OEM.

8:

What is not an advantage of OFA?

  • A. It allows you to separate objects with different behaviors into different tablespaces.

  • B. It assists you with organization of a large amount of software components, products, and data.

  • C. It allows you to install all binaries into the same Oracle home.

  • D. It helps to separate software from data.

A8:

Answer C is correct; the only given answer that is not an advantage of OFA is that it allows you to install all binaries into a single Oracle home. Separation into individual Oracle homes is a vital way to maintain Oracle software products and is the only way to install different versions of the binaries on a single physical server.

9:

What is the default password for SYS when the database is created with DBCA?

  • A. change_on_install.

  • B. manager.

  • C. sys.

  • D. DBCA forces you to create your own SYS password.

A9:

Answer D is correct; DBCA makes you choose your own password for both the SYS and SYSTEM users. Answer A is incorrect; change_on_install is the default password if you create the database manually. Answer B is incorrect; manager is the default SYSTEM password if you create the database manually. Answer C is incorrect; sys is not anyone's default password.

10:

You have been hired as a DBA in a company. What tool would you use to get a quick idea of all the databases running in the company?

  • A. OEM

  • B. OUI

  • C. SQL*Plus

  • D. DBCA

A10:

Answer A is correct; OEM can give you an overall idea of all running databases and their objects and components. Answer B is incorrect; OUI installs databases but does not provide any information on already running databases. Answer C is incorrect; you need a basic idea of what databases are accessible to use SQL*Plus. Answer D is incorrect; DBCA configures an existing database but does not tell you what databases are running.


Chapter 3. Creating a Database

Terms you'll need to understand:

  • CREATE DATABASE

  • Oracle Database Configuration Assistant

  • ODCA

  • Control files

  • Oracle Base

  • Oracle Home

  • Oracle SID

  • Templates

  • SID

  • Online Transaction Processing

  • MAXLOGFILES

  • MAXLOGMEMBERS

  • MAXLOGHISTORY

  • MAXDATAFILES

Concepts you'll need to master:

  • Understand the prerequisites necessary for database creation.

  • Create a database using the Oracle Database Configuration Assistant.

  • Create a database manually.

Creating a database, although not a task that you will undertake every day, is certainly a task that will be very important in your career as a DBA. It is something that will take thought and planning and something that you should understand early, both in your career and in your exam preparations. This chapter shows you how to create a database manually and use the GUI interface.

Creating a database is, naturally, the first step in managing a database. The database may be one created automatically as a part of the initial Oracle 9i Server installation, or it can be created later, either using the Database Configuration Assistant or manually with database creation scripts. If you are migrating a database from an earlier version (8i, for example), you can accomplish this either through the use of the database migration assistant or the use of migration scripts.

Database creation is the task of preparing several operating system files. It is a task needed only once for a database, regardless of how many data files that database ultimately has. Because of the importance of this task, careful decisions must be made on many of the database settings.


Prerequisites for Database Creation

To create a new database, you must have the following:

  • A privileged account authenticated either by the operating system or by use of a password file.

  • Sufficient memory on the computer to allow the instance to start. This needs to be large enough for the entire SGA, the Oracle executables, and the processes supporting the instance.

  • Sufficient disk space for the planned database. Included in your calculations needs to be the disk space that is necessary for the database, its data files, the online redo log files (including the multiplexed files), and the control files (including any multiplexed versions).

  • Sufficient disk space for archive logs for the planned database. Include in your calculations sufficient disk space to store archived redo log files. Although a data warehouse may not need to have archive logs for normal operations, it is important to have them for a period of time to facilitate recovery of the database.

Chapter 2, "Getting Started with the Oracle Server," covers authentication further.


Planning Database File Locations

Oracle advises that you distribute your database files in a way that facilitates performance and reliability.

At least two active copies of the database's control files should be kept on at least two different devices.

Redo log files should be multiplexed and each group of members be put on different disks.

Data files whose data will have different life spans (as in a data warehouse or read-only tablespaces versus an Online Transaction Processing system) should be distributed on different disks.

Data with different life spans (for example, application data and temporary sort data) should be separated into different tablespaces (and by extension into different datafiles) to minimize fragmentation.

Data with different administrative characteristics (read-only tablespaces separated from highly active tables separated from marginally active tables) should be separated onto different disks.

Any data, or data and indexes on that same data, that will participate in resource contention should be placed on different physical disks.

Refer to Chapter 8, "Maintaining Control Files," for information regarding control files.

Refer to Chapter 9, "Maintaining Redo Log Files," for information regarding redo log files.

Refer to Chapter 10, "Managing Tablespaces and Data Files," for more information on these topics.

Oracle further suggests that data files be named with the root of the name relating to the context of the data that will be stored within that data file. For example, General Ledger data may have a GL prefix to the data file such as gldata or glindex, and user-specific data may have a prefix of u or user as in data or userdata.


Creating the Database

Creating a database can either be done manually, using SQL scripts and the CREATE DATABASE command, or with the Database Creation Assistant (DBCA).

Before you can create a database, either manually, or with DBCA, the operating system environment needs to be configured properly, or the database will fail to create correctly.

ORACLE_BASE specifies the topmost directory that will house the Oracle software.

For example: /Oracle or C:\Oracle.

ORACLE_HOME provides the directory where the Oracle software will be installed. Oracle Flexible Architecture suggests that the value of the ORACLE_HOME be set to ORACLE_BASE/product/release#.

For example: /Oracle/product/9_2 or C:\Oracle\database\9_2.

ORACLE_SID is the instance name. This must be unique for all Oracle instances that will be running on the same physical computer.

For example: PROD, DEVELOPMENT, TEST.

Although PATH is not necessarily set only for the Oracle installation but also for ease of navigation and use for users in general both on Unix and Windows platforms, it is important that portions of your path be set to allow for efficient searches for the executables (such as SQL*Plus). Most particularly, it is important for your path to include the ORACLE_HOME/bin directory.

ORA_NLS33 is an optionally set variable that is required when you are going to be creating a database with a character set other than US7ASCII. It is suggested that this point to a subdirectory of the ORACLE_HOME.

For example: ORACLE_HOME/nls/data or ORACLE_HOME\nls\data.

LD_LIBRARY_PATH specifies the directory for operating system and Oracle library files associated with the Oracle instance.

For example: ORACLE_HOME/lib or ORACLE_HOME\lib.


Oracle Database Configuration Assistant

The Database Configuration Assistant (DBCA) is a graphical user interface that interacts with the Oracle Universal Installer when you choose to create a database automatically when you install the Oracle 9i Server. Figure 3.1 shows the initial screen presented when working with the DBCA. Alternatively, it can be used as a standalone program. Its purpose is to simplify the creation of a database. The DBCA is a Java-based interface that can be launched from any platform that has access to a Java engine.

Figure 3.1. Using the Database Configuration Assistant.

[View full size image]

During installation of the server software, DBCA is launched by the Universal Installer and can automatically create a starter database if you want it to. You can choose at this point whether to use the DBCA at this time, use it later to assist you with database creation, or create your database manually.

With the DBCA, you can not only create a database, you can also configure database options, delete existing databases, and manage templates.

To launch the DBCA on Unix, type dbca at the Unix prompt. In Windows, you can launch the assistant from the Windows operating system Start menu where it is found under Configuration Assistants.

On a Unix platform, you need to be running an XWindows session either on the terminal or on your PC to run the DBCA product.

When you start the DBCA, you are presented with a screen with four options:

  • Create a Database

  • Configure Database Options in a Database

  • Delete a Database

  • Manage Templates

Figure 3.2 shows an example of the screen on which you can make these choices.

Figure 3.2. DBCA options screen.

[View full size image]

Create a Database

This option allows you to create a new database or a database template. The default template allows you to choose to create a database either with or without data files.

Without datafiles contains only the structure of the database, but allows you to specify or change all the database parameters.

With datafiles contains both the structure and the physical datafiles of the database. All the log files and control files are automatically created for the database, but you can add or remove control files and/or log groups. You can also change the destination and name of any or all of the data files. You cannot add or remove datafiles, tablespaces, or rollback segments. You cannot change initialization parameters.

Whenever you create a database with the DBCA, you need to specify the global database name as well as the unique SID. What's more, you need to decide what added features you want in your resulting database. These added features that you can choose to add to your installation include the following:

  • Oracle Spatial

  • Oracle Intermedia (or Oracle Text)

  • Oracle OLAP Services

  • Example Schemas

  • Human Resources

  • Order Entry

  • Product Media

  • Sales History

  • Shipping

When you are creating a database with the DBCA, you have the option of creating either a typical or a custom database.

A custom database allows you to customize the creation of your database. This option is only for experienced database administrators with advanced knowledge of the database creation process. This advanced knowledge includes experience with the data, control, and redo settings; tablespace and extent sizing; database memory parameters and other initialization parameters; archive log formats and destinations; trace file destinations; and character set values.

A typical database creation with minimal user input allows you to choose the following different types of databases to mimic.

The steps involved in creating a database with DBCA include the following:

  • Create Database Create the database immediately.

  • Save as a Database Template Save creation parameters as a template and that template is added to the list of available templates.

  • Generate Database Creation Scripts Save the database creation parameters as a script file for later use.

  • Determine the type of database that you want to create:

    • Online Transaction Processing (OLTP) An OLTP database typically must be capable of processing many thousands of transactions (read, write, update, delete) from many concurrent users every day. Performance, in an OLTP, is in terms of throughput of transactions and availability of data.

    • Data Warehouse These databases must be capable of processing a wide variety of queries; however, they are typically read-only queries. These processes range from simple queries that fetch a few records, to queries that many long-running complex queries take hours to process. Data Warehouse database performance is measured in terms of response time.

    • Multipurpose Many environments require a combination of the two different kinds of processing. A mixed database supports both OLTP and Data Warehousing environments. This is the default database that will be installed using DBCA.

Figure 3.3 shows your choices as they apply to database type to create.

Figure 3.3. Selecting a database type.

[View full size image]

Database Configuration Options

The Configure Database option lets you add options to your database that had not previously been configured. These include (if they are available for your installation) JVM, InterMedia, Visual Information Retrieval, Spatial, Oracle OLAP services, advanced replication, and SQL*Plus help.

The Configure Database option is not available in the 9i Real Application Clusters installation.

Additional database configuration options, some shown earlier in Figure 3.2, include the following:

  • Delete a Database Allows you to delete a database.

  • Manage Templates Allows you to create a template through one of three methods:

    • From predefined template settings Create a new template from the predefined template settings; add or change any settings, parameters, storage characteristics; or use custom scripts.

    • From an existing database, structure only Contains the structural information similar to an existing database. The structure, in this case, means all the database options as well (the tablespaces, datafiles, and initialization parameters) specified in the source database. No schemas or data will be a part of the created database.

    • From an existing database, structure and data Create a database that copies the structure as well as the data of the existing database. User-defined schemas and their data will be a part of the template. You are not allowed to add or remove any data files, tablespaces, or rollback segments.

  • Required Parameters Besides the information already covered, the creation of an Oracle Database and Oracle instance requires some further decisions to be made, particularly if you are choosing the custom database creation option. Figure 3.4 shows you a tabbed page on which you can choose various SGA settings, character sets to define for your database, data block sizing decisions, file locations, and archive log locations for the database.

    Figure 3.4. Choosing database parameters.

    [View full size image]

  • Archive Parameters Archive redo logs are used for database recovery and often for implementation of a standby database. Running your database in archive log mode enables the archiving of redo log files before those redo files are reused. This is done for the purpose of recovery facilitation.

    It is often not necessary, or wise, to put a Data Warehouse database into archive log mode. Because Data Warehouses are updated infrequently, and typically by means of a bulk SQL*Ldr job, creating logs for restoration purposes in this case is often simply a waste of resources.

  • Data Block Sizing DB_BLOCK_SIZE helps to define the default database block size and determine the SORT_AREA_SIZE. DB_BLOCK_SIZE, the parameter that gets set during the use of this parameter, can be specified only at database creation time. SORT_AREA_SIZE is the amount of memory used for sorting operations.

    Remember that the only time you can set the DB_BLOCK_SIZE of the database, regardless of the method used to create the database, is at database creation time. If for any reason you determine later that you have chosen an incorrect value for this parameter, the database has to be rebuilt.

  • File Locations By using the UDUMP, BDUMP, and CDUMP parameters, you can specify the particular locations for trace files.

    More information about the Initialization Parameter file can be found in Chapter 4, "Managing an Instance."

  • Database Storage This helps you to specify the storage parameters for the various files in your database creation. You can make custom alterations to the control files (do you want to multiplex?), tablespaces (do you want to have dictionary managed or locally managed?), datafiles, undo segments (do you want the new, and Oracle suggested, Automatic Undo Management, or do you want to manage rollback segments manually?), and redo log groups (how many log groups do you want, where do you want them, and do you want to multiplex them?).

Note that, if you do not change the default behavior, DBCA creates datafiles with autoextend turned on. You could easily run a file system, or hard drive, out of space if you leave the default behavior for a production database or a development database where you have limited control over the amounts of data being inserted or loaded.


Create a Database Manually

Even if your company standardizes on using the GUI tools, such as DBCA, it would be a good idea to create a database manually at least once, not only to help you with this test (although it will help you to pass this portion of the exam), but so that you have an idea of what the DBCA is doing behind the scenes. This knowledge will help you to make more informed decisions in creating your databases, going forward, regardless of how you create them.

Step 1: Decide on Your Instance's System Identifier (SID)

The first step in creating the database is to determine the System Identifier (SID). This is what the environment will be set to when your database starts up and shuts down, and what the instance processes will have in their names as unique identifiers.

Step 2: Create the Initialization Parameter File

In the ORACLE_HOME/dbs directory, a set of generic initialization files are available for you to copy and customize to your situation. There is one for a regular OLTP database, one for a data warehouse database, and one for a combination database. Find the one that most closely matches what you intend your database to be used for, copy it to another name (saving the template for reuse later), and make your specific alterations to the copy.

Name the copied init.ora file init<SID>.ora because this is the default naming convention that the Oracle server looks for when it tries to start up the instance.

Edit this file's parameters so that your database and your instance will run effectively on your system.

Let's address the parameters in the initialization file in greater depth:

  • DB_NAME Must be set to a text string of eight characters or less. During database creation, the value assigned to DB_NAME is recorded in the database's datafiles, redo log files, and control files. If, when you attempt to start the database instance, the value of DB_NAME as recorded in the initialization parameter file and the database name in the control files are not the same, the database will not start.

  • DB_DOMAIN A text string that specifies the network domain where the database is created. This is often the name of the organization that owns the database. If the new database will be a part of a distributed database system, special attention needs to be paid to this parameter before database creation.

  • CONTROL_FILES Is assigned the comma-separated list of control file names to use for the new database. When you execute the CREATE DATABASE statement, the control files listed as values assigned to this parameter are created. If you fail to specify a filename for the CONTROL_FILES parameter, Oracle creates a file with a default operating system dependant filename.

  • DB_BLOCK_SIZE Specifies the standard block size of the database. This size is used in the creation of the system tablespace and by default in any other tablespaces created. Take care when determining what this value should be because after the database is created, the value cannot be changed.

  • UNDO_MANAGEMENT Determines whether the database starts in automatic undo management mode. A value of AUTO enables automatic undo management; MANUAL enables manual undo management mode. In 9i, AUTO is suggested, but MANUAL is default.

  • UNDO_TABLESPACE When the instance starts in automatic undo management mode, it needs to have a tablespace in which to store its undo information. The default is SYS_UNDOTBS and is automatically created if you execute a CREATE DATABASE statement with the UNDO_MANAGEMENT initialization parameter set to AUTO and no UNDO TABLESPACE statement in the CREATE DATABASE statement.

Step 3: Connect to and Start the Instance

Connect to the instance as SYSDBA either using operating system authentication or the password file method of authentication and start up the instance using the STARTUP command.

>sqlplus '/ as sysdba'

If your parameter file is not in the default location or is not named init<SID>.ora, you may need to specify the PFILE clause in the STARTUP command for the instance to start.

Because you do not yet have a database attached to the instance, you need to start up the instance in NOMOUNT state:

SQL> startup nomount;

The instance is now started and ready for the CREATE DATABASE command.

There are several options for starting up the database. The following are the ways that you can start up the instance and the database, and what each means:

  • STARTUP NOMOUNT Starts the instance but does not mount the database.

  • STARTUP MOUNT Starts the instance and mounts the database but does not open the database.

  • STARTUP OPEN Starts the instance and mounts and opens the database.

  • STARTUP RESTRICT Starts the instance, mounts and opens the database; however, access is restricted to users with restricted session privileges.

  • STARTUP RECOVER Starts the instance but leaves the database closed and begins recovery for whatever failure scenario occurred.

  • STARTUP FORCE Forces the instance to shutdown abort and immediately startup open. This option should only be used for instances having problems either starting or stopping.

Step 4: Issue the CREATE DATABASE Statement

To create the database, issue the CREATE DATABASE command. The CREATE DATABASE command creates data files, control files, redo log files, the system tablespace along with the data file associated with it, and a system rollback segment. It creates the tables that underlie the data dictionary, assigns the character set to the database, optionally sets the database time zone, and mounts and opens the database for use.

The general format follows:

CREATE DATABASE [database name]
[CONTROLFILE REUSE]
[LOGFILE [GROUP integer] file specification]
[MAXLOGFILES integer]
[MAXLOGMEMBERS integer]
[MAXLOGHISTORY integer]
[MAXDATAFILES integer]
[MAXINSTANCES integer]
[ARCHIVELOG|NOARCHIVELOG]
[CHARACTER SET charset]
[NATIONAL CHARACTER SET charset]
[DATAFILE filespec [AUTOEXTEND]]
[DEFAULT TEMPORARY TABLESPACE tablespace filespec]
[UNDO TABLESPACE tablespace DATAFILE filespec]
[SET TIME_ZONE [time_zone_region]];

Database is the name of the database that you are creating. If the name of the database is omitted, the initialization parameter DB_NAME is used. The database name should be the same as the DB_NAME parameter.

Control file reuse specifies that an existing control file identified by the control file parameter in the initialization file should be reused.

Log file group identifies the names of the log files to be used and the group to which they belong.

MAXLOGFILES specifies the maximum number of redo log files that can ever be created in the database.

MAXLOGMEMBERS specifies the maximum number of redo log file members that any given log file group can have in the database.

MAXLOGHISTORY specifies the maximum number of archive redo logs for automatic media recovery.

AUTOEXTEND enables or disables the automatic extension of SYSTEM tablespace's data files in the database.

MAXDATAFILES controls the initial sizing of the data file section of the control file at the time when the CREATE DATABASE or CREATE CONTROLFILE commands are issued. If an attempt is made to add a new file with a number greater than the value set to the MAXDATAFILES parameter, but less than the DB_FILES parameter, it causes the control file to expand automatically so that the data files section can accommodate the new files.

The MAXINSTANCES parameter is optional and is primarily used for Real Application Clusters (RAC) environments. The default, if left unspecified, is 1.

The optional ARCHIVELOG|NOARCHIVELOG statement provides the option for the database's redo log files to automatically initially be archived. This is an optional statement at database creation time. NOARCHIVELOG is the default if ARCHIVELOG is not specified. If, after database creation, you choose to change the archive log mode of the database, you can use the ALTER DATABASE command to change between the two. ARCHIVELOG establishes that the redo logs can be reused, but only after they have been archived. NOARCHIVELOG establishes that the redo logs can be reused without archiving their contents.

CHARACTER SET is the character set that the database uses to store the data.

The NATIONAL CHARACTER SET parameter is optional and is used to store data in columns specifically defined as NCHAR, NCLOB, or NVARCHAR2.

More on National Language Support (NLS) and its associated parameters will be covered in Chapter 7, "Globalization Support."

DATAFILE, when connected directly to the CREATE DATABASE statement, is the file specification used to specify the data files to be used for the system tablespace.

DEFAULT TEMPORARY TABLESPACE instructs the database to assign this tablespace to all users created without having a temporary tablespace specified.

UNDO TABLESPACE creates and names the undo tablespace and the associated data files that should be used to store undo records for the database if you have specified (as Oracle suggests) UNDO_MANAGEMENT=AUTO in the initialization parameter file.

A working example of a CREATE DATABASE script follows:

CREATE DATABASE mydb1 CONTROLFILE REUSE
LOGFILE
GROUP 1 ('/mydatabases/mydb1/log01a.log', '/mydatabase02/mydb1/log01b.log') SIZE 50M,
GROUP 2 ('/mydatabases/mydb1/log02a.log', '/mydatabase02/mydb1/log02b.log') SIZE 50M,
GROUP 3 ('/mydatabases/mydb1/log03a.log', '/mydatabase02/mydb1/log03b.log') SIZE 50M,
GROUP 4 ('/mydatabases/mydb1/log04a.log', '/mydatabase02/mydb1/log04b.log') SIZE 50M
DATAFILE '/mydatabases/mydb1/mydb1_system.dbf' 250M
AUTOEXTEND ON MAXSIZE 500M
UNDO TABLESPACE mydb1_undo1
DATAFILE '/mydatabases/mydb1/mydb1_undo1.dbf' 50M
DEFAULT TEMPORARY TABLESPACE mydb1temp tempfile '/mydatabases/mydb1/mydb1temp1.dbf' size 75M
EXTENT MANAGEMENT LOCAL
CHARACTER SET US7ASCII
MAXLOGFILES 10
MAXLOGMEMBERS 10
MAXLOGHISTORY 1
MAXDATAFILES 500;

If you use the CONTROLFILE REUSE command, make absolutely sure that you don't specify a control file attached to another database. The reuse command will cause it to be overwritten. Although this will not cause the database and instance to crash (the one that had the control file overwritten) immediately, it is cause for care and concern. Oracle will not tell you that you are overwriting the wrong file, and, if you don't realize it, this can cause the overwritten database to not start after it is shut down.

If you are using Oracle Managed File (OMF) systems and you have specified the appropriate OMF initialization parameters in the parameter file (DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_DEST_n), the following statement creates the database:

STARTUP NOMOUNT
CREATE DATABASE
DEFAULT TEMPORARY TABLESPACE mydb1temp;

At this point, your database now contains data files (at least a limited number of them), control files, redo log files, the SYS and SYSTEM users, and all the internal data dictionary tables, but no data dictionary views. You can see the dynamic performance views, such as V$LOGFIEL, V$CONTROLFILE, and V$DATAFILE. If you have not yet changed the default passwords for SYS (change_on_install) and SYSTEM (manager), now is a good time to do it.

Step 5: Run Scripts to Build Data Dictionary Views

Now that you have a database, you need to complete the data dictionary views and procedures. In the ORACLE_HOME/rdbms/admin directory, a pair of scripts need to be run to complete the database's data dictionary creation. CATALOG.sql creates the data dictionary views from which you can gain insight into the contents of the database. CATPROC.sql creates the objects required to use PL/SQL.

Step 6: Run Scripts to Install Additional Options

This step is optional. However, if you need to add any of the optional products, such as Spatial or InterMedia, you can now run the scripts to add these products to your database. You can locate the scripts and the following procedures in the Oracle documentation.

Step 7: Create a Server Parameter File

This step is optional, although highly recommended by Oracle. Your Oracle database was created by starting the instance with a parameter file, or PFILE. Because it is editable, you can migrate, easily, your new database to using a server parameter file. Creation of the server parameter file (or spfile) is accomplished by issuing the following statement:

CREATE SPFILE FROM PFILE;

This command looks in the default location (ORACLE_HOME/dbs) for an initialization parameter file (or PFILE) with the default name. If your database is named mydb1, the default name would be initmydb1.ora. The command creates an spfile with the default name in the same default location unless otherwise specified.

More on parameter files and server parameter files can be found in Chapter 4.

Step 8: Back Up the Database

Now that your database is created, take this chance to shut down the database and take a cold backup of the new database.

Step 9: Create Additional Tablespaces

After the backups are finished, you can restart the database and create new tablespaces, tables, and users; add data; and in general, open the new database for business.


What to Do If Database Creation Fails

Database creation fails if there are syntax errors in the SQL for the CREATE DATABASE script, if files that you are trying to create already exist, or if there are operating system errors such as inadequate directory permissions or not enough space in the file system.

If any of these problems occur, you need to delete any files that may have been created (with the exception of the control files if the REUSE statement is used), make alterations to the CREATE DATABASE statement as needed (correcting any errors), and attempt the creation again.


Exam Prep Questions

1:

What three tablespaces can be created using the CREATE DATABASE statement? [Select three]

  • A. Undotbs1

  • B. System

  • C. Users

  • D. Datatbs

  • E. Indextbs

  • F. Temporary

A1:

Answers A, B, and F are correct. The three tablespaces that you can create at database creation time are the Undo tablespace (which defaults to the name in A if none is given and automatic undo is used), a default temporary tablespace, and the system tablespace (SYSTEM is the only one that is mandatory). Although Users (C), Datatbs (D), and Indextbs (E) may be valid tablespaces, they have to be created after the database is created.

2:

What should you do as soon as you have successfully created the database and the data dictionary?

  • A. Open the database for users to start adding data.

  • B. Start adding a bunch of tablespaces to allow users to use.

  • C. Leave it running for a few days to make sure that nothing bad is going to happen.

  • D. Shut it down and take a cold backup.

A2:

Answer D is correct. As soon as you have successfully created the database and the data dictionary, you should shut down the database and take a cold backup to make sure that you have a fallback point should something happen later. Answer A is incorrect because many things can happen to a database when users are accessing it, and you would, at this point, have to re-create the database if anything should happen to the database that would cause you to have to restore, you would have a backup to restore from. Answer B is incorrect. Adding a lot of tablespaces could only complicate your initial restore if you should have to recover the new database. Answer C is incorrect because nothing will really be lost but definitely nothing will be gained from simply letting the database run for a while.

3:

What should you not do if your database creation script fails?

  • A. Check the SQL Syntax.

  • B. Make sure that there is sufficient space in the file system or directory or drive.

  • C. Rerun the script immediately.

  • D. Delete existing files.

A3:

Answer C is correct. Rerunning the script immediately won't resolve any issues and will likely present you with new ones that may cloud the original issue. Answer A should be done first; check to see whether you have syntax errors in your CREATE DATABASE script. Answer B should be done next; make sure that you have enough space in the place you are using for your files to house them. Answer D should be done right before you are ready to run the script again; leaving files out in the same location will likely cause your script to fail again.

4:

What starts the instance and allows users to access the database?

  • A. STARTUP NOMOUNT

  • B. STARTUP OPEN

  • C. STARTUP MOUNT

  • D. STARTUP RESTRICT

A4:

Answer B is correct. STARTUP OPEN opens the instance and the database to allow users to connect to the database. Answer A is usually only used for database creation and starts just the instance. Answer C starts the instance and mounts the database, but at this point it can only be accessed by someone with sysdba authority. Answer D is incorrect because RESTRICT signifies that only privileged users (sysdba and those with restricted session authority) can access the instance and the database.

5:

You are using the DBCA and you need to change some of the templates that you have stored. What option from the first screen would you use to accomplish this?

  • A. Create Database

  • B. Manage Templates

  • C. Configure Database Options in Database

  • D. Change All Templates

A5:

Answer B is correct; you want to manage templates. Answer A is incorrect; you would use this option to create a new database. Answer C is incorrect; you would use this option to change configuration settings in a database that already exists. Answer D is incorrect; it is not an option in the DBCA.

6:

Which three operations can be accomplished through the Database Creation Assistant? [Choose three]

  • A. Create Database

  • B. Maintain Database

  • C. Delete Database

  • D. Alter Database

  • E. Configure Database

A6:

Answers A, C, and E are correct. Through the DBCA, you can create, delete, or configure an existing database. Answer B is incorrect because that is what you do with most of your time as a DBA and can be done with the assistance of Oracle Enterprise Manager. Answer D is incorrect; OEM and command line are the means by which you can alter the database.

7:

What GUI tool is provided by Oracle to assist in the creation of databases?

  • A. DBCA

  • B. OEM

  • C. SQL Plus

  • D. Java

A7:

Answer A is correct. Database Creation Assistant (DBCA) is the GUI tool provided to assist with the creation of databases. Answer B, OEM, is the tool that assists database administrators with daily routine maintenance of the database. Answer C is a command-linelike interface through which users can submit SQL queries (it can run in Windows as a GUI interface or native on any other platform). Answer D in incorrect; Java is a programming language that is the basis for many of the Oracle tools but is not the interface.

8:

What is the minimum number of control files that Oracle suggests for a database?

  • A. 1

  • B. 2

  • C. 3 groups

  • D. 0

A8:

Answer B is correct. Oracle suggests having at least two control files for a production database. Answer A is the minimum number necessary to run a database. Answer C is the suggested number of redo log groups. Answer D is incorrect because there needs to be at least one available control file for database operation.

9:

You need to determine the placement of your multiplexed CONTROL FILES in the database that you are creating. With what parameter in the CREATE DATABASE script would you specify the location?

  • A. control_files

  • B. controlfile

  • C. logfile

  • D. datafile

A9:

Answer A is correct; you specify the name and location of the CONTROL FILES with the controlfile parameter in the CREATE DATABASE script. Answer B is incorrect; the control_files parameter is in the initialization files. Answer C is incorrect; it specifies the location of the online redo log files. Answer D is incorrect; the datafile parameter isn't in the initialization file but is a specification of the tablespace creation command.

10:

Which is not a necessary decision to make at database creation time?

  • A. Location of the control files

  • B. Location of the redo log files

  • C. Location of the SYSTEM tablespace's data files

  • D. Location of all the data files that will belong to the database

A10:

Answer D is correct; it is not necessary to know the location of every data file that will be connected to your database at database creation time. Answers A, B, and C are incorrect because they are all necessary information for creation of the database initially.


Need to Know More?

You should study the operating system installation and administration guides for your given operating system.


Chapter 4. Managing an Instance

Terms you'll need to understand:

  • DB_NAME

  • Startup

  • Shutdown

  • Initialization parameter file

  • V$SESSION

  • Alert log

  • Background_dump_dest

  • User_dump_dest

  • Core_dump_dest

  • MAX_DUMP_FILE_SIZE

  • SQL_TRACE

Concepts you'll need to master:

  • Create and manage initialization parameter files.

  • Configure Oracle Managed File Systems.

  • Start up the instance.

  • Shut down the instance.

  • Monitor and use diagnostic files.

In this chapter, you learn how, together, Oracle and you manage the instance and its processes. It is in this area that you will typically spend a considerable percentage of your time as a DBA, and a basic understanding is critical.


Initialization Parameter Files

To start the instance, Oracle must read from an initialization parameter file to determine how to configure the SGA and in general how to run the instance and its database.

Entries in the initialization files are specific to the instance that is going to be accessed. There are two kinds of parameters, explicit and implicit. Explicit parameters have entries in the parameter file. Implicit parameters are implied by taking on the Oracle default values but have no entry within the parameter file.

Although the values within parameter files are specific to a single instance, and a parameter file can only be used for its particular instance, more than one parameter file can be used for an instance to optimize performance for different situations.

Changes to entries in the file take effect based on the type of parameter file used. Entries in the PFILE are static (to have a static parameter's changes take effect, the instance needs to be restarted). Those parameters in an SPFILE are persistent. (Persistent parameters can be changed in the active instance, take effect in the active instance, and persist across restarts of the instance.)

It is important to understand that you cannot have the database started with both the PFILE and the SPFILE at the same time. Only one can be in use in any given instance at any one time.

The parameter files contain a list of instance parameters; the name of the database and instance to which it is associated; memory structure allocation for the SGA; names, locations, and reusability of the redo log files; names and locations of the control files; and information pertaining to the undo segments for the instance.

Working with PFILE

The PFILE, commonly referred to as the init SID.ora file, is known as a static parameter file.

The PFILE is a simple flat text file that can be modified manually in any operating system text editor. The changes made to the init SID.ora file don't take effect until the next time the database is started (in fact, the file is in a read-only state during instance startup), and its default location is $ORACLE_HOME/dbs on Unix or %ORACLE_HOME\database on the Windows platform.

A sample init.ora file is placed in the default location by the Oracle Installer during the initial installation of the database binaries, and this file can be used (copied) to provide customized, instance-specific settings for your environment.

The keyword value specification in the PFILE parameters takes the following form:

Keyword=value

There are several points to remember about the parameter file:

  • White space is ignored, and all parameters are optional because the server has a default value for each parameter (some are operating system dependent according to the operating system and parameter).

  • The parameters can be in any order in the file; you should determine the manner in which you want to group the parameters in your parameter file and follow that standard for all parameter files, not because Oracle cares, but because it makes it easier for you to find parameters later regardless of what parameter file you are examining.

  • Comment lines in the parameter file are signified by lines that begin with the "#" symbol.

  • The IFILE parameter signifies that the value to which the parameter is set is an included file, called into the parameter file when the instance is started.

  • If a parameter takes on a list of values, those values are enclosed in parentheses and comma separated.

If the operating system recognizes case sensitivity, the filenames in the parameter file need to follow that sensitivity.

One important reason to group parameters in a consistent manner is that, if you accidentally list a parameter more than once, and the values for the parameter are not identical in both cases, the last value in the parameter file will take precedence and overwrite any other value that you have set. This can have unanticipated consequences.

An example of an init SID.ora file follows:

[View full width]

#initialization parameter file: initmydb1.ora
db_name = "mydb1"
instance_name = mydb1
control_files = ("/mydatabases/mydb1/control01.ctl", "/mydatabases2/mydb1/control02.ctl",
   "/mydatabases3/mydb1/control03.ctl")
open_cursors = 100
shared_pool_size  = 360407040
large_pool_size = 614400
java_pool_size = 52428800
processes = 220
background_dump_dest = /mydatabases/mydb1/logs/bdump
core_dump_dest = /mydatabases/mydb1/logs/cdump
user_dump_dest = /mydatabases/mydb1/logs/udump
db_block_size = 8192
compatible = "9.1.0"
sort_area_size = 65536
sort_area_retained_size = 65536

Table 4.1 lists commonly used initiation parameters and provides a brief description of their use. Remember that these parameters are version 9.2.0.1 settings and may be slightly different in other versions. A complete, version-specific list can be found in the Reference Guide of the Oracle documentation set for the version that you are using.

Table 4.1. Commonly Configured Parameters

Parameter Name

Description

BACKGROUND_DUMP_DEST

Specifies the directory where the trace files generated by the background processes are to be written. This is also the location of the alert log for the database.

COMPATIBLE

Provides Oracle with the understanding of what features you intend the database to have. If there is a feature in 9i that was not available in 8i and this parameter is set to 8.1.7, the feature will fail to perform.

CONTROL_FILES

The location of the control files for the database.

DB_BLOCK_SIZE

The default block size for the database.

USER_DUMP_DEST

Specifies the directory where the trace files generated by user sessions are written.

CORE_DUMP_DEST

Specifies the location where core dump files generated by Oracle are written.

DB_NAME

The name of the database and also of the SID.

INSTANCE_NAME

The name of the instance and, with the exception of a RAC environment, also the database and the SID.

OPEN_CURSORS

The maximum number of cursors that you want to have opened in your instance at any given time.

PROCESSES

The maximum number of processes permitted to be connected to the instance at any given time.

Working with SPFILE

The SPFILE, known more commonly as the spfile SID.ora, can be thought of as a persistent parameter file. The default location for the SPFILE is $ORACLE_HOME/dbs in Unix or $ORACLE_HOME\database directory in Windows. It is a binary file (although it is easily viewable in Unixdon't edit it) that has the capability to store and make available changes that are both dynamic and also persistent across shutdown of the instance and startup again. The SPFILE is maintained by the Oracle Server (and it is important that you not manually make changes to this file) with parameter value changes made with the ALTER SYSTEM command.

ALTER SYSTEM SET UNDO TABLESPACE = 'UNDOTBSP2';

Values for the parameters can be deleted or reset to allow the instance to revert, for those parameters, back to the default values.

You can specify when you issue the ALTER SYSTEM command whether the changes should be made temporarily or should persist across shutdown and startup. The following settings specify what scope the changes should take:

  • MEMORY signifies that the changes to the parameter value should be effective only in the currently running instance, but should not persist across shutdown and startup. This is often done to see what effect the changes will have, when the effect may be determined to be detrimental and you want to easily be able to back out of the change.

  • SPFILE signifies that the parameter value should change only in the SPFILE.

  • BOTH signifies that the parameter value should change not only in the currently running instance but also in the SPFILE to make it persistent across shutdown and startup. BOTH is the default, so make sure that you know what your command is doing if you don't specify the command's scope.

The form that the command takes is as follows:

ALTER SYSTEM SET <parameter> = <value> [SCOPE=MEMROY|SPFILE|BOTH]

Creating the SPFILE

The SPFILE can be created from the PFILE using the CREATE SPFILE command. This can be issued at any time before or after the instance has started and is run from the SQL prompt when logged in as someone with SYSDBA privileges.

CREATE SPFILE FROM PFILE;

or

CREATE SPFILE=<SPFILE NAME> FROM PFILE=<PFILE NAME>;

SPFILE NAME is the name that you want specified for the SPFILE if you don't want the default name of spfile SID.ora. PFILE NAME is the name you have given the parameter file, init SID.ora, which is assumed.

You can create an editable version of the values in the SPFILE by creating the PFILE from the SPFILE. You can then edit the resulting PFILE and then re-create the SPFILE from that. The command to create the PFILE from the SPFILE follows:

CREATE PFILE FROM SPFILE;

An interesting thing about re-creating the PFILE in this manner is that the parameters in the resulting file show up in alphabetic order.

Modifying the SPFILE

The SPFILE can be modified; however, it has to be modified indirectly, either through the OEM interface or from the SQLPLUS command line.

Modifying the SPFILE Using OEM

To modify the SPFILE using the GUI OEM interface, you launch the console either in standalone mode or by connecting to an existing repository. Expand the database that you are working on from the Database folder, expand the Instance folder, and click on Configuration.

The interface can be launched both by issuing the command oemapp console at the command line and by launching through the Windows Start menu.

Within the General tab, click the All Initialization Parameters button to see the parameters that you can work with. They are viewed in alphabetical order. If you have logged in as SYSDBA, you can modify both the working instance parameters as well as the SPFILE values, both the dynamic parameters as well as the static ones. If you don't log in as someone with SYSDBA authority, you can alter only dynamic parameters.

Modify the parameter's value column and click OK.

To alter the contents of the SPFILE from the SQL prompt command line, you could enter the following command (this alters the running session and makes the change in the SPFILE):

Alter system set open_cursors=4000 scope=both;

Table 4.2 shows the parameters that the ALTER SYSTEM command can take when you are using an SPFILE.

Table 4.2. ALTER SYSTEM Command Parameters for SPFILE

Parameter

Value Example

Description

COMMENT

I changed this parameter because…

Puts a comment on the parameter line that is changed.

DEFERRED

Changes the value for the parameter for any new sessions connecting after the statement is issued while leaving the parameter as it was previously for already connected sessions.

SCOPE

Specifies when the change will take effect and takes any of the following three values.

MEMORY

The change takes effect immediately for the running instance.

SPFILE

The change is made in the server parameter file (SPFILE) only, but the changes will not take place until the next startup.

BOTH

This is the combination of MEMORY + SPFILE. It will be available now and will still be available after next startup; this is the default.

SID

Specifies the SID of the instance where you want this value to apply. This is applicable to a Real Application Clusters (RAC) environment and applies to all instances; this is the default.

The following is an excerpt from what you might see in your SPFILE. Notice that the parameters are in alphabetic order. This is helpful when trying to find parameters and their values.

^@^@
*.db_block_size=8192
*.db_domain='WORLD'
*.db_file_multiblock_read_count=16
*.db_files=1022
*.db_name='mydb1'

Comments in the PFILE are carried over into the SPFILE only if they are specified on the same line as the parameter in the PFILE. If they are not on the same line as the parameter, they are not transferred to the SPFILE.

Specifying Often-Used Initialization Parameters

Regardless of whether you are using the PFILE or the SPFILE, no parameters are, strictly speaking, required. However, several should be specified in your environment and customized for your individual databases, if necessary. There are others that are most frequently altered in most organizations.

Table 4.3 shows these parameters along with their description.

Table 4.3. Often-Used Initialization Parameters

Parameter

Description

BACKGROUND_DUMP_DEST

The location where the background processes trace files are written (arch, dbw, lgwr, and so on). Also the location where the alert files are written.

This parameter should be specified.

COMPATIBLE

The version of the server with which the instance should be compatible.

This parameter should be specified.

CONTROL_FILES

Name and location of the control files.

This parameter should be specified.

DB_BLOCK_BUFFERS (deprecated for DB_CACHE_SIZE but still supported)

The number of blocks cached in the SGA.

This parameter should be specified.

DB_BLOCK_SIZE

The default block size in the database.

This parameter should be specified.

DB_NAME

The database identifier that consists of eight characters or less. This is the only parameter that is absolutely required when the database is created but can be acquired from the create database statement if you don't supply it in the initialization file.

This parameter should be specified.

IFILE

The name of additional parameter files to be embedded within the current parameter file. Up to three levels of nested files are possible.

This is a commonly modified parameter.

LOG_BUFFER

The number of bytes allocated to the redo log buffers in the SGA.

This is a commonly modified parameter.

MAX_DUMP_FILE_SIZE

The maximum size of the trace files. This is specified as the number of operating system blocks.

This is a commonly modified parameter.

PROCESSES

The maximum number of operating system processes that can simultaneously connect to an instance.

This is a commonly modified parameter.

SHARED_POOL_SIZE

The size of the shared pool in bytes.

This parameter should be specified.

SQL_TRACE

This enables or disables the SQL trace facility for every user session.

This is a commonly modified parameter.

TIMED_STATISTICS

This enables or disables the timing in trace files and in monitor screens.

This is a commonly modified parameter.

USER_DUMP_DEST

The location where the trace files go that are used for debugging user transaction failures. The trace files are created on behalf of the user processes.

This parameter should be specified.


Oracle Managed File (OMF) System

Oracle Managed Files simplify the administration of certain types of Oracle databases. These files help with administration by eliminating the need for the database administrator to directly manage the files associated with the Oracle database. Oracle Managed Files are created and deleted by the Oracle Server based on parameters specified in the PFILE or the SPFILE initialization file.

Initialization File Parameters for OMF

To take advantage of OMF, parameters need to be specified in the parameter files. These parameters and their explanation follow:

  • DB_CREATE_FILE_DEST Provides the default location for the data files.

  • DB_CREATE_ONLINE_LOG_DEST_n Provides the default location for the online redo logs and control files. You can specify up to a maximum of five locations for this parameter.

Both of these parameters do not have to be set to use OMF; they are independent parameters. Setting one allows you to use that functionality while leaving the other manually managed.

Furthermore, these parameters are dynamic parameters, meaning that they can be altered at any time by using the ALTER SYSTEM SET command.

Remember, you can specify up to five locations for the DB_CREATE_ONLINE_LOG_DEST_n parameter.

OMF Naming Conventions

Oracle not only controls the maintenance of the database files, but it also controls the naming of these files. Table 4.4 shows what each of these filenames typically looks like.

Table 4.4. Oracle Managed File Types

File Type

Filename Format Examples

Control files

ora_%u.ctl

Redo log files

ora_%g_%u.log

Data files

ora_%t_%u.dbf

Temporary data files

ora_%t_%u.tmp

Undo files

ora_%t_%u.dbf

The wildcards %g, %t, and %u have the following definitions:

  • %g The redo log file group number.

  • %t The tablespace name, truncated as necessary to ensure that it fits into the maximum filename. By placing the tablespace name before the uniqueness string, you allow all the data files for a given tablespace to appear together in an alphabetical listing of files.

  • %u An eight-character character string that guarantees uniqueness.

  • ora_ Signifies that the file is an Oracle Managed File.

For example, if you want to create a database with Oracle Managed Files for the data files (data files, temp files, and undo files), control files, and online redo log files, and have the control files and log files created in their own separate directories, you would set the initialization parameters as follows:

On Unix:

DB_CREATE_FILE_DEST = '/mydatabse/mydb1/'
DB_CREATE_ONLINE_LOG_DEST_1 = '/mydblogs1/mydb1/'
DB_CREATE_ONLINE_LOG_DEST_2 = '/mydblogs2/mydb1/'

On Windows:

DB_CREATE_FILE_DEST = 'c:\mydatabse\mydb1\'
DB_CREATE_ONLINE_LOG_DEST_1 = 'c:\mydblogs1\mydb1\'
DB_CREATE_ONLINE_LOG_DEST_2 = 'c:\mydblogs2\mydb1\'

Then issue the CREATE DATABASE statement as follows:

CREATE DATABASE mydb1;

This allows the control files and redo log files to be duplexed across the /mydblogs1 (c:\mydblogs1) and /mydblogs2 (c:\mydblogs2) directories.

If the CREATE DATABASE statement fails when you are using OMF, any files that have been created are removed. Although this is true of dropping tablespaces in general with OMF (that the system also drops the data files at the same time as the tablespace), it is important to remember that simply failing the CREATE DATABASE statement will clean up after itself.

You can find out the internally generated filenames by selecting from the DBA_DATAFILES data dictionary view for the data files, or the V$LOGFILE data dictionary view for log files.


Database Startup

When starting the database, you have control over the state in which it ultimately starts. There are several different ways to start the database (MOUNT, NOMOUNT, OPEN, RESTRICT), and these are covered in this section.

STARTUP NOMOUNT

The STARTUP NOMOUNT command starts up the instance but does not mount or open the database. This usually is reserved for times when you are creating a database or need to re-create the control files.

When Oracle starts the instance, it reads the initialization file from the default location, unless otherwise specified. It looks for these files in the following order:

  1. spfile SID.ora

  2. spfile.ora

  3. init SID.ora

You can override this default behavior by specifying:

STARTUP NOMOUNT pfile=<path_to_pfile>/mypfilename.ora

Next, during STARTUP NOMOUNT, Oracle allocates the SGA, starts up the background processes, and opens the alert (alert SID.log) and any trace files.

The name of the database that you are starting must either be named with the DB_NAME parameter in the initialization file or be specified in the startup command.

STARTUP MOUNT

STARTUP MOUNT is used to perform certain maintenance operations. This starts up the instance and mounts but does not open the database.

Tasks that need to be accomplished with the database mounted but not open include the following:

  • Rename data files

  • Offline drop data files

  • Enable redo log archiving options

  • Disable redo log archiving options

  • Perform full database recovery

Mounting the database associates that database with a started instance. Oracle opens the control files specified in the parameter file and then reads the control files to determine the names, status, and location of data files and redo log files. There are no checks at this point to verify the existence of the data files or the online redo log files at this time. This is why you can perform file maintenance with the database in this state.

STARTUP OPEN

STARTUP OPEN leaves the database in a normal operational state. This means that the instance is started; the database is mounted and open to the point where any valid Oracle user can access the database, connect, and perform typical data operations. This means that the online data files are open, and the online redo log files are also open. If any online database's data file or if all your online redo logs are not present when you attempt to open the database, Oracle returns an error. If you are using multiplexed redo logs and only one member of the group is unavailable, Oracle still opens the database.

During the final stage of opening the database, the Oracle Server verifies that all the data files, including undo tablespace files and temporary tablespace files, can indeed be opened and checks all the files to ensure the consistency of the database. If necessary, SMON (or the System Monitor background process) initiates an instance recovery to ensure consistency.


Working with the STARTUP Command

When the STARTUP command is given, it is inferred that, if you do not specify, you intend for the instance to be started, the database to be mounted and opened for operation, or STARUP OPEN. The order of operations is as follows:

  1. The command STARTUP is issued.

  2. The instance opens in the NOMOUNT state.

  3. The database is mounted.

  4. The database is opened for access.

The following are a few examples of variations with the STARTUP command:

  • STARTUP Starts up and opens the database inferred by whatever the SID environment variable is set to with the default SPFILE if available or PFILE.

  • STARTUP mydb1 Starts up and opens the mydb1 database with the default SPFILE if available or PFILE.

  • STARTUP OPEN mydb1 In effect, has the same outcome as the previous example, only explicitly assures the one issuing the command that he is indeed opening the database.

The following command starts up and opens the database named in the init.ora parameter file:

STARTUP pfile=$ORACLE_HOME/dbs/initmydb1.ora

The general form of the STARTUP command is as follows:

Startup [FORCE|RESTRICT|MOUNT|NOMOUNT|OPEN|RECOVER] [database name] [pfile=<filename>]

Table 4.5 provides the names and meanings for the variables in this form of the STARTUP command. Although this is not the exhaustive list, it is the most common commands and the ones that might find their way into the exam.

Table 4.5. STARTUP Parameters and Their Meanings

Parameter

Meaning

Open

Enables any user to access the database

Mount

Mounts the database and enables certain DBA tasks to be performed but does not allow users to access the database

Nomount

Creates the SGA and starts the background processes but does not allow access to the database

PFILE= Parameterfile

Enables the DBA to specify a nondefault parameter file to be used to configure the instance

Force

Startup force aborts the running instance and then issues a STARTUP NORMAL

Restrict

Enables any user with restricted session privilege to access the database

Recover

Begins media recovery when the database starts

By default, Oracle looks in %ORACLE_HOME%\database (Windows) or $ORACLE_HOME/dbs (Unix) for the initialization parameter file. It first tries to find the spfileSID.ora and then initSID.ora, if nothing is otherwise specified. If none are located, an error message is received.

Automating Startup

On Unix, you can automate database startup and shutdown by utilizing independent operating system routines that read the entries in a special file, particularly the oratab file located in the /var/opt/oracle directory and use those entries to assist the automation.

On Windows, you can start the database automatically by creating a service in your system that automatically calls the executable that starts the database on your system. These services are automatically installed with the Oracle installer and are configured automatically for you when you use the Database Configuration Assistant. You can set the database instance to start in Automatic, Manual, or Disabled mode in the Windows services.

You can find extensive information on this in the installation guide for the operating system.

Altering the Database State

If you start up the database in MOUNT or NOMOUNT mode, and, after completing your maintenance, decide that you are ready to open the database, from NOMOUNT to MOUNT, the command is as follows:

ALTER DATABASE mydb1 MOUNT;

To alter the database from NOMOUNT to MOUNT (or restrict or recover) to read-only, the command is as follows:

ALTER DATABASE mydb1 OPEN READ ONLY;

Setting Restricted Mode

The database can be placed into restricted mode in either of two ways. First, the DBA can issue the restricted mode command at database startup as follows:

STARTUP RESTRICT

Alternatively, the DBA can alter the system and place the database in restricted session mode:

ALTER SYSTEM ENABLE RESTRICTED SESSION;

ENABLE RESTRICTED SESSION does nothing to sessions currently logged on; however, future logons are only enabled for users who have been granted RESTRICTED SESSION privilege.

To allow users who don't have RESTRICTED SESSION privilege to again be able to log on and access the database, you can use the following command:

ALTER SYSTEM DISABLE RESTRICTED SESSION;

RESTRICTED SESSION is useful when performing structural maintenance or an import or export (although it is not necessary for an import/export operation to be in restricted session mode).

If you use the ALTER SYSTEM ENABLE RESTRICTED SESSION command, you may want to kill any currently connected user sessions before starting any administrative tasks. This will be safer for your database and anything being done in those sessions. You can find the sessions that you should kill by selecting information from the V$SESSION view.

You can run the following script first to find all active sessions and then to kill all active sessions in the database:

SELECT SID, SERIAL# FROM V$SESSION WHERE USERNAME NOT IN ('SYS', 'SYSTEM');

ALTER SYSTEM KILL SESSION 'integer1, interger2'

integer1 is SID, and integer2 is SERIAL#.

The Session ID and the serial number of the session are used to uniquely identify sessions. This guarantees that your ALTER SYSTEM KILL SESSION command kills the correct session, even if the original user logs off and a new session uses the same Session ID. Narrowing the sessions that are killed allows you to make sure that you are not killing yourself. Killing your own session isn't the end of the world. You can log back on because you, as SYS and SYSTEM, have restricted session privilege, but it is something that can be avoided.

When the sessions are killed, PMON (Process Monitor) rolls back the user's current transaction, releases all the held locks at the table and row level, and frees all the resources reserved by the users.

Setting Read-Only Mode

You can open your database in a read-only mode as long as you don't already have it open for read-write. When the database is in read-only mode, users can connect and execute queries, and cause disk sorts to occur if the user's default temporary tablespace is a locally managed tablespace (this means that more complex queries can be executed with order by or group by clauses). If the user's default tablespace is not a locally managed tablespace, any query run by that user that causes disk sorts will fail.

Locally managed tablespaces will be covered Chapter 10, "Managing Tablespaces and Data Files."

Read-only mode is particularly useful if you want to use the read-only database as a standby database, or as a way to offload query processing from a production online transaction processing database.

A read-only database does not restrict the DBA's ability to perform recovery operations or to make any changes to the database's current state as long as those changes do not cause redo data to be generated. When your database is in read-only mode, you can take individual data files online and offline, instead of having to offline complete tablespaces. You can then perform recovery on offline data files or tablespaces.

To maintain information in nondata related files, such as control files, operating system audit trail files, trace files, and alert log files, writes to these structures continue to occur even when the database is in read-only mode.


Shutting Down the Database

When you shut down the database, you can make operating system level (cold) offline backups of all physical structures. A shutdown allows static initialization parameters to take effect at the next startup.

To shut down the instance and its associated database, a user with SYSOPER or SYSDBA privilege uses the SHUTDOWN command with the following:

SHUTDOWN [NORMAL| TRANSACTIONAL |IMMEDIATE | ABORT]

NORMAL is the default if no option is specified.

SHUTDOWN NORMAL

During a SHUTDOWN NORMAL, the database buffer cache is written to the data files as the SHUTDOWN command forces a checkpoint, uncommitted changes are rolled back, and resources are rolled back. The database is in a consistent state when it is completely closed. When an instance is started after a SHUTDOWN NORMAL, no instance recovery is needed.

No new connections are allowed to the instance, but the Oracle Server waits for all the currently connected users to disconnect before completing the shutdown. SHUTDOWN NORMAL is the most polite way to shut down the database but can also be the least practical. In SHUTDOWN NORMAL, because users are not killed, shutdown could take a long time if user sessions are forced to disconnect after a given period of idle time. Often users will simply lock their computers and go home at the end of the day without logging off their application.

Redo buffers are written to disk during a SHUTDOWN NORMAL. This is important, because if something should happen during the shutdown or during the period during which the database is shut down, and the database cannot start in a consistent manner, the redo log files will allow it to start up and recover to the point where it was shut down.

Background processes are terminated, and the SGA is removed from the computer's memory as Oracle closes and dismounts the database and then shuts down the instance.

SHUTDOWN TRANSACTIONAL

SHUTDOWN TRANSACTIONAL prevents users from losing any work.

During a SHUTDOWN TRANSACTIONAL, the database buffer cache is written to the data files, resources are rolled back. The database is in a consistent state when it is completely closed. When an instance is started after a SHUTDOWN TRANSACTIONAL, no instance recovery is needed.

Users cannot start new transactions through any interface, but the session is disconnected as soon as the active user session completes the transaction that is in progress. After all transactions are finished, all users will be logged off, and the instance shuts down immediately. This makes SHUTDOWN TRANSACTIONAL more practical than SHUTDOWN NORMAL from the DBAs perspective and still allows for no lost work from the users' perspective.

A checkpoint is forced, making sure that the redo buffers are written to disk.

SHUTDOWN IMMEDIATE

During a SHUTDOWN IMMEDIATE, the database buffer cache is written to the data files, uncommitted changes are rolled back, and resources are rolled back. The database is in a consistent state when it is completely closed. When an instance is started after a SHUTDOWN IMMEDIATE, no instance recovery is needed.

Currently active SQL statements in process are not completed. This means that work could be lost from a user's perspective.

Oracle does not wait for any transaction to finish or for any user to disconnect from the database.

A checkpoint is forced, the active redo buffers are written out to the online redo logs, and active transactions are rolled back as active users are disconnected. The time that it takes for rollback to complete can be extensive, depending on how much work the active transactions in the database were doing.

Oracle dismounts the database, closes the database, and shuts down the instance.

SHUTDOWN ABORT

SHUTDOWN ABORT simulates either an instance failure or a startup force. When the instance and database shut down, no buffers are written to data files, nothing is rolled back, and no checkpoints are taken.

At the point when the instance is closed, the database is in an inconsistent state.

When the database restarts from a SHUTDOWN ABORT, redo logs are used to reapply changes that were currently active in the database at the abort point. Then undo segments are used to roll back all uncommitted changes. Only at this point are the resources released and user connections permitted to the reopened database.

SQL statements that are currently being processed are immediately terminated. Oracle doesn't wait for any transactions to finish or for users to disconnect. Redo information in the buffers are not written to disk. Database buffers are not written to disk.

The instance does not close files, and the database is not closed or dismounted. Instance recovery occurs automatically during the next startup.

Shutting Down and Starting Up Using OEM

From the running OEM interface, expand the database you want to access from the Database folder. Expand that database's Instance folder, and click on Configuration.

From the General tab, select the instance state that you want the database to be in and click Apply.

The requirements for allowing shutdown or startup through the OEM interface are that you be connected to OEM as a user with SYSDBA privilege.


Managing the Instance by Monitoring the Diagnostic Files

Oracle's diagnostic files are a means to capture vital information that concerns significant events encountered while the instance is operational. These files are used to resolve problems with the instance and to better manage the efficient operation of the database.

Several types of diagnostic files exist in connection with the database. Different types of diagnostic files exist for different types of problems that occur and need their information disseminated.

Alert Log

The alert SID.log file contains information about the day-to-day operation of the database. Oracle writes to the alert log everything that happens when the database is successfully started and shut down. This includes the time and status of all log switches, and any information concerning a tablespace or data file alteration. Any time a trace file is written, it is referenced in the alert SID.log file. Each entry has a time stamp associated with it. This makes it easier to determine what happened when the database was started or shut down. The DBA manages the alert SID.log file in the location specified by the BACKGROUND_DUMP_DEST initialization file parameter. The default location on the Unix system is $ORACLE_HOME/rdbms/log.

If this file does not exist when the instance starts, Oracle automatically creates it. The alert log should always be the first place the DBA looks if there is a need to diagnose any operational errors that occur in the database.

Within the alert SID.log file, you can find the following information:

  • The date and time of all database startup and shutdown operations

  • All nondefault initialization parameters for the database

  • The startup of the background processes

  • The log sequence number that log writer is writing and the time of the writing

  • Creation of any tablespace

  • Creation and deletion of undo segments

  • Alter statements that have changed the state of the database (data files, tablespaces, system, or database)

  • Information connected to critical error messages in the database

Background Trace Files

Background trace files contain vital information that gets written any time background processes (system monitor, process monitor, log writer, archiver, and others) fail. These files are used to diagnose and troubleshoot errors and are created only whenever any background process encounters errors that require writing out information to the files. These files contain header information indicating the version number of the database server and versions of the operating systems.

The background trace files are located, naturally, in the file system designated by the BACKGROND_DUMP_DESTINATION and have the naming convention sid_processname_process-id.trc (for example, mydb1_pmon_12345.trc).

User Trace Files

User trace files contain important information for fatal user errors or user forced trace files. These files contain the SQL statement that was running when the errors were encountered, statistics for the statement, the user running the query (the Oracle user as well as the OS user) errored, and the error encountered. User trace files can be created deliberately, too, as a way of helping the DBA to troubleshoot performance issues occurring in the database.

User trace files are located in the file system designated by the USER_DUMP_DEST initialization parameter and has its maximum size defined by the MAX_DUMP_FILE_SIZE parameter (if left unset, it defaults to 10 megabytes).

The naming convention for the user trace file is sid_ora_process-id.trc (for example, mydb1_ora_654321.trc).

User tracing is enabled or disabled either at the session level or the instance level by setting any of the following commands or parameters:

  • ALTER SESSION Allows you to set the tracing to enabled or disabled at the session level.

    • ALTER SESSION SET SQL_TRACE = TRUE

    • ALTER SESSION SET SQL_TRACE = FALSE

  • DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION The DBMS_SYSTEM package has as one of its procedures the SET_SQL_TRACE_IN_SESSION.

  • SQL_TRACE You can set the user trace to enabled or disabled at the instance level by setting the initialization parameter SQL_TRACE to trUE or FALSE.

    • SQL_TRACE = TRUE

    • SQL_TRACE = FALSE


Exam Prep Questions

1:

Which two commands start up the instance and leave the database mounted and normal users unable to log in? [Select two answers]

  • A. startup nomount

  • B. startup restrict

  • C. startup mount

  • D. startup open

  • E. STARTUP read-only

A1:

Answers B and C are correct. STARTUP MOUNT allows the DBA to perform certain types of maintenance that cannot be accomplished when the database is open, and STARTUP RESTRICT opens the database yet allows the DBA to perform other types of maintenance that cannot be accomplished when users are logged in. Both require special privileges to allow the user to connect. Answer A starts the instance but does not mount the database. Answer D is the default and allows any user to log in and manipulate data in the database. Answer E allows users to connect but not to perform any action that would cause a redo to be generated.

2:

If you have a parameter file named init mydb1.ora, and you are logged in as SYS, what would the following code sample accomplish?

CREATE SPFILE FROM PFILE;

  • A. It would create the init mydb1.ora SPFILE and place it in the default location.

  • B. It would create the SPFILE init mydb1.ora and put it in a user-defined location.

  • C. It would fail because you don't have any parameters specified.

  • D. It would create the SPFILE init mydb1.ora and place it in the default location.

A2:

Answer D is correct. If you were to issue the command as given while logged in as a user with SYSDBA privileges, you would create the SPFILE spfile mydb1.ora from the existing parameter files. Answer A is incorrect because the init mydb1.ora file is a parameter file, and Oracle won't create the SPFILE with that name unless instructed specifically to do so; however, because no path is specified, the default location for all files is inferred. Answer B is incorrect for the same reason that Answer A is incorrect; Oracle will not create the SPFILE with the same name as the PFILE, and there is no custom location provided for either file. Answer C is incorrect because the syntax is correct as long as the person issuing the command is logged in as someone with SYSDBA privileges; any parameters are optional for the CREATE SPFILE option and are used to allow you to customize your implementation.

3:

Which of the following describes the parameter file? [Select all that apply]

  • A. A binary file editable only by Oracle

  • B. A flat text file alterable in any text editor

  • C. The default file that Oracle looks for first when starting the instance

  • D. A file that is read-only when the instance is started

  • E. A file that contains dynamically alterable parameters for the database

  • F. A file that allows you to customize the parameters that you want to set to the nondefault settings for your instance and database

A3:

Answers B, D, and F are correct. The parameter file, or PFILE, is a simple text file that is alterable in any text editor, is read-only when the instance is starting, and also allows you to customize settings for your database instance. Answer A is incorrect; the SPFILE is the binary file editable only by Oracle. Answer C is incorrect because in Oracle 9i, Oracle first looks for the SPFILE in the default location before it looks for the parameter file. Answer E is incorrect because the PFILE contains static parameters; the SPFILE contains dynamically alterable parameters.

4:

Which of the following are valid places where initialization parameters can be found for use when the database is starting up? [Select all that apply]

  • A. control01.ctl

  • B. initmydb1.ora

  • C. system01.dbf

  • D. spfilemydb1.ora

A4:

Answers B and D are correct. Oracle looks in the SPFILE and the INIT file for its initialization parameters. Answer A is a control file and provides useful information to the database and instance, but does not contain initialization parameters. Answer C is a data file, not a parameter file.

5:

Which is not an initialization parameter used for the Oracle Managed File System?

  • A. DB_CREATE_FILE_DEST

  • B. DB_CREATE_REDO_LOG

  • C. DB_CREATE_ONLINE_LOG_1

  • D. DB_CREATE_ONLINE_LOG_2

A5:

Answer B is correct. DB_CREATE_REDO_LOG is not a valid OMF initialization parameter. Answer A designates where Oracle should place its data files. Answer C is the location where Oracle puts one copy of multiplexed log and control files. Answer D is the location where Oracle puts another copy of the multiplexed log files.

6:

What two tools can be used for starting up and shutting down the Oracle instance and database? [Select two]

  • A. SQL Plus

  • B. Server Manager

  • C. Enterprise Manager

  • D. PL/SQL

A6:

Answers A and C are both tools that can be used for starting up and shutting down the database. Answer B is incorrect; Server Manager used to be a tool that you could use, but it is no longer available with Oracle 9i. Answer D is incorrect; PL/SQL cannot be used to shut down and start up the database.

7:

You are creating a new control file to replace ones that have been deleted. Which of the following commands is the appropriate way to start the database?

  • A. Startup nomount

  • B. Startup read-only

  • C. Startup open

  • D. Startup

A7:

Answer A is correct. STARTUP NOMOUNT allows you to create a new control file without worrying about it attempting to access or open data files. Answer B is incorrect because the data files and control files have to be accessible and open for the queries in a read-only database to be processed. Answer C is incorrect because the control file has to be available to open the database. Answer D is simply a restatement of answer C and is therefore incorrect for the same reasons.

8:

Which pair of words complete the following statement?

When you issue the STARTUP NOMOUNT command, the Oracle instance is _____________, and the Oracle database is ______________?

  • A. Started, not mounted

  • B. Started, mounted

  • C. Started, opened

  • D. Not started, not mounted

A8:

Answer A is correct. When you use STARTUP NOMOUNT, the instance is started, and the database is not mounted. Answer B is incorrect because NOMOUNT means that the database has not been mounted. Answer C is incorrect because the database is neither mounted nor opened. Answer D is incorrect because the instance is started, and the database is not mounted.

9:

It seems to be taking longer to start the instance after it has been shut down with the SHUTDOWN ABORT command. Why might this be the case?

  • A. You are anxious to get on to something else, and it just feels longer.

  • B. Oracle has to check to make sure that all the data files, control files, and redo log files are in a consistent state while it is starting back up.

  • C. Oracle just wants you to use SHUTDOWN ABORT in appropriate times and has built in a delay mechanism to make sure that you do.

  • D. It takes Oracle longer to open files after a SHUTDOWN ABORT has occurred.

A9:

Answer B is correct, Oracle must ensure that the database is in a consistent state before it finally opens, and, after a SHUTDOWN ABORT, this can take an extended period of time. Answer A is incorrect; although it may be true that you want to get on to something else, it is also true that Oracle takes longer to restart in a SHUTDOWN ABORT situation. Answer C is incorrect; there is no delay mechanism to make sure that you don't use a shutdown type. Answer D is incorrect. It takes Oracle the same amount of time to open the files; ensuring consistent state takes the extra time.

10:

Under normal circumstance, which of the following SHUTDOWN methods can take the longest time?

  • A. SHUTDOWN ABORT

  • B. SHUTDOWN IMMEDIATE

  • C. SHUTDOWN AT TIME 0100

  • D. SHUTDOWN TRANSACTIONAL

A10:

Answer D is correct. SHUTDOWN TRANSACTIONAL can take a lot longer if you have many users on the database and they aren't logging out. Answer A is incorrect. ABORT is the fastest because it does no checking; it just stops. Answer B is incorrect. SHUTDOWN IMMEDIATE doesn't wait for anyone, but disconnects users and shuts down gracefully. Answer C is incorrect; there is no SHUTDOWN AT TIME command.


Need to Know More?

If you want to know more about maintaining the instance, you can find information in the Reference Guide from http://tahiti.oracle.com and in the administration guide from the same website.


Chapter 5. Data Dictionary Content and Usage

Terms you'll need to understand:

  • Data dictionary

  • catalog.sql

  • catproc.sql

  • Dynamic performance views

  • DBA_ views

  • USER_ views

  • ALL_ views

  • V$ views

Concepts you'll need to master:

  • Identify key data dictionary components.

  • Identify the contents of the data dictionary.

  • Identify the uses of the data dictionary.

  • Query the data dictionary.

The data dicntionary is one of the most powerful and often relied on components of the Oracle database. This chapter introduces the data dictionary and how you can gain valuable information from this resource.


Oracle's Data Dictionary

During the creation of the database, the Oracle Server creates additional physical objects in the datafiles and logical structures within the instance. These structures assist in the running of the database and the location of other structures.

These structures include a set of read-only tables and views that record and provide verification and other information about the database to which it belongs.

In the data dictionary there are base tables that store the description of the database and its components. These base tables are created behind the scenes automatically when you issue the CREATE DATABASE command (Oracle runs sql.bsq to create them). They are the first structures in any Oracle database. The Oracle Server writes to these tables whenever there is a need to update any of them. It is the only thing that should ever write to these tables; no data definition language (DDL) or data manipulation language (DML) should ever be run to update any of these tables with the exception, possibly, of the AUD$ tables that are connected to auditing.

More information on the AUD$ tables can be found in Chapter 17, "Managing Privileges."

Also inside the data dictionary are the data dictionary views that summarize and compartmentalize the base table information. These views allow for a more useful and formatted presentation, including object names rather than simply the stored object numbers. These read-only views are created when you run the catalog.sql script located in the $ORACLE_HOME/rdbms/admin (for UNIX) or %ORACLE_HOME%\rdbms\admin (on Windows) directory.

Through these tables and views, you can learn more about the definitions and names, definitions and space allocations of objects, and integrity constraints on the various objects. You can learn about users, their roles and privileges, and information about auditing these users' actions.

The data dictionary contains the following:

  • The definitions of all the schemas in the database

  • The definitions of the tables, views, indexes, clusters, synonyms, sequences, procedures, packages, functions, triggers, and other schema objects

  • The space that has been allocated and used by each of the schema objects in the database

  • The default values for columns in the tables in the database

  • The integrity constraints for objects in the database

  • The check and not null constraints for objects in the database

  • The userid (name) of Oracle users

  • The privileges and roles that have been granted to each Oracle user

  • The auditing information that might exist that is connected to anyone who has accessed, or updated, a variety of defined schema objects

The data dictionary keeps track of every aspect of your database. It keeps track of tables and users, tablespaces and objects, space allocation, and every connection that has been made to the database. It is a key component of the database and should be treated as such.

The data dictionary is located in the system tablespace and usually needs to be re-created when you upgrade the database from one version of the server to another.


How the Data Dictionary Is Used

The Oracle Server, users (DBAs and regular users alike), and programs access the data dictionary to find information about users, schema objects, and storage structures. The data contained in the data dictionary are needed for the server to function properly. This is why you should never, ever update the information in these tables manually. The data is read whenever the database is operational to determine whether objects exist and what users have what access to those objects. Information in the data dictionary is modified whenever a Data Definition Language (DDL) statement is executed in the instance.

Users and database administrators can use the data dictionary views as a reference. Some views are accessible to any Oracle user; others are intended to be viewed by database administrators only.

The data dictionary is not a single entity. It is made of individual components, some of which are supporting program units; others are tables and views on tables.

Program Units

Program units, also often known as stored procedures, are PL/SQL programs stored in the database rather than as external programs at the operating system level. Program units include functions, procedures, and packages. The data dictionary includes many Oracle-provided program units for use in the database. Many are there only for the support of other components of the database, such as PL/SQL, Java programs stored in the database, and even Java Enterprise Beans, whereas others are there for you to use in your day-to-day life as a DBA. Still others allow programmers and developers to access and use many of the useful functions of the Oracle Server.

Views on Base Tables

Different types of views can be found in the Oracle data dictionary, including static views and dynamic views. The following sections discuss the differences between these two types of views and what those different views are used for.

Static Views

The data dictionary views are static views that answer specific questions about objects, users, and privileges. These static views change only when there is an alteration, addition, or deletion of objects from the database. These views have the distinct characteristics of being prefixed with either the USER_, ALL_, or DBA_ prefix. Examples of questions that these views answer are as follows:

  • When was the object created?

  • What is this object a part of?

  • Who owns the object?

  • Is the object valid?

  • What privileges does this user have?

  • When was this user created?

  • What profile does this user have?

Dynamic Performance Views

Dynamic performance views, also known as the V$ views or performance views, provide an actively changing view into current database activity. Throughout the duration of the instance being operational, the Oracle Server maintains these virtual tables (virtual in that they reside in memory rather than on disk and are defined as views) with information reflecting real-time conditions in the database. These views, which are owned by the SYS user, are continually updated while the database is operational with information accessed from memory and the control file, among other places. DML on these views is not permitted.

DBAs use these views to monitor and tune the database. From the V$ views you could answer the following kinds of questions:

  • Is this object online?

  • Is this object available?

  • Is this object open?

  • Is this service active?

  • Is this user logged on?

  • What query is this user running that is running away?

The data dictionary has three main types of static views. These views fall into three main categories that can be distinguished from each other by their scope as follows:

  • DBA_ (DBA_TABLES, for example) Provide information about the objects in all schemas in the database. They contain references to all objects within the database instance.

  • All_ (ALL_TABLES) Provide information on all the objects accessible to the user who is making the query. For every DBA_ view, there is a corresponding ALL_ view that allows users to see objects to which they have been granted access. For example, the following command set shows how to use DBA_TABLES, USER_TABLES, and ALL_TABLES to see what tables that user SCOTT has access to. First, find out what table SCOTT owns from DBA_TABLES:

    SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES WHERE OWNER = 'SCOTT'
OWNER                          TABLE_NAME
------------------------------ ------------------------------
SCOTT                          BONUS
SCOTT                          DEPT
SCOTT                          EMP
SCOTT                          SALGRADE

    Now, let's look at what shows up when you select from ALL_TABLES when logged in as SCOTT:

    SQL> SELECT OWNER, TABLE_NAME FROM ALL_TABLES;
OWNER                          TABLE_NAME
------------------------------ ------------------------------
SYS                            DUAL
SYS                            SYSTEM_PRIVILEGE_MAP
SYS                            TABLE_PRIVILEGE_MAP
SYS                            STMT_AUDIT_OPTION_MAP
SYSTEM                         DEF$_TEMP$LOB
WMSYS                          WM$WORKSPACES_TABLE
SYSTEM                         HELP
MDSYS                          OGIS_SPATIAL_REFERENCE_SYSTEMS
MDSYS                          USER_CS_SRS
MDSYS                          USER_TRANSFORM_MAP
MDSYS                          SDO_DIST_UNITS
MDSYS                          SDO_AREA_UNITS
MDSYS                          SDO_ANGLE_UNITS
CTXSYS                         DR$POLICY_TAB
MDSYS                          CS_SRS
MDSYS                          SDO_ELLIPSOIDS
MDSYS                          SDO_PROJECTIONS
MDSYS                          SDO_DATUMS
WKSYS                          WK$SYS_CONFIG
WKSYS                          WK$CRAWLER_CONFIG_DEFAULT
WKSYS                          WK$MIMETYPES
WKSYS                          WK$CHARSET
WKSYS                          WK$LANG
SCOTT                          DEPT
SCOTT                          EMP
SCOTT                          BONUS
SCOTT                          SALGRADE
SYS                            AUDIT_ACTIONS
SYS                            PSTUBTBL
SYS                            ODCI_SECOBJ$
SYS                            ODCI_WARNINGS$

    And now we look at USER_TABLES when logged in as user SCOTT:

    SQL> SELECT TABLE_NAME FROM USER_TABLES
TABLE_NAME
------------------------------
BONUS
DEPT
EMP
SALGRADE
Select * from ALL_TABLES;

    These objects include not only those that the user owns, but all those to which the user has been given privileges.

  • USER_ Provide information on objects owned by the current user. For every DBA_ view and every ALL_ view, there is a corresponding USER_ view designed to show those objects that the given user owns.

Now that we have discussed the different kinds of views in the data dictionary, we will look at retrieving information from this valuable asset.


Accessing Data Dictionary and Dynamic Performance Views

During normal database operation, Oracle accesses data dictionary contents almost continuously. It expects these structures to be as they were created by the Oracle scripts and therefore should never be altered.

To make these views more usable for DBAs and other users, Oracle creates public synonyms for many of the data dictionary views. Public synonyms are aliases created for objects in the database that are available to everyone who connects to the database to use. These public aliases allow anyone who wants to access the object in question to do so without having to prefix the object name with the owner's schema name. Often these synonyms are on global type tables or packages that have broad application and limited security requirements (such as a single predefined calendar table with all the dates from 1900 to 3000 in it). These can be contrasted with private synonyms granted from one schema to another schema individually as the need arises. This allows the views to more easily be accessed by anyone regardless of the way that he is logged in; you don't have to prefix them with the SYS user's prefix. DBAs can also, after considering security implications, create additional public synonyms for objects used systemwide.

Because of the system implications, it is important that users avoid naming their own schema objects with the same name as those used for the public synonyms for data dictionary objects.

To determine what is available in the data dictionary, you can query the DICTIONARY view. After you have found a likely view, you can then DESCRIBE the view to learn the columns associated with that view and then SELECT the information relevant in your situation.

An example of a query that you can run against the DICTIONARY data dictionary view follows. This query can provide you with an extensive listing of what is in the data dictionary and the kind of information that can be found, and where.

COLUMN table_name FORMAT A30
COLUMN COMMENTS FORMAT A45 WORD_WRAP
SELECT table_name, COMMENTS
FROM DICTIONARY;

A representative sample of the output of this query appears in Table 5.1.

Table 5.1. Data Dictionary Views

Table Name

Comments

DBA_TAB_MODIFICATIONS

Information regarding modifications to tables.

DBA_TAB_PRIVS

All grants on objects in the database.

DBA_SYNONYMS

All synonyms in the database.

DBA_SYS_PRIVS

System privileges granted to users and roles.

DBA_RGROUP

All refresh groups. This view is not a join.

DBA_ROLES

All roles that exist in the database.

DBA_ROLE_PRIVS

Roles granted directly to users or granted to other roles.

DBA_ROLLBACK_SEGS

Description of rollback segments.

DBA_RSRC_CONSUMER_GROUPS

All the resource consumer groups.

DBA_RSRC_CONSUMER_GROUP_PRIVS

Switch privileges for consumer groups.

DBA_RSRC_MANAGER_SYSTEM_PRIVS

System privileges for the resource manager.

DBA_RSRC_PLANS

All the resource plans.

DBA_RSRC_PLAN_DIRECTIVES

All the resource plan directives.

DBA_RULES

Rules in the database.

If you need more information about what a particular column means than you can get from just describing the view, the Comments column in Table 5.1 can provide insight into what each column's contents mean.

There are synonyms for the DICTIONARY view. CAT, CATALOG, and DICT are all other names referring to the same view, and all can be used interchangeably. This may occur on the exam as a means to trip you up.

Any Oracle product can reference existing views and can (and typically do) create additional data dictionary views of their own.

Application programs, written by in-house or contracted developers who write programs that reference the data dictionary for any reason, should always refer to the public synonyms and never to the underlying tables. This is not only safer for the Oracle software, it also is safer for the accessing programs because the public synonyms' contents are less likely to change from release to release, whereas the underlying tables are more apt to.

Some of the views are designed to be accessible by all users; others by database administrators only. The prefix of the view (for example, DBA_, USER_, or ALL_) usually provides a clue to which views are designed for whom.

Fast Access of the Data Dictionary

Much of the data dictionary information is kept in the SGA in the data dictionary cache. This is done because Oracle constantly accesses the data dictionary during operation. The information stored in the data dictionary cache is aged out using the least recently used algorithm.

Parsing information is almost continuously found in the data dictionary cache. Comments describing the tables and their contents are not cached unless they are accessed frequently enough to qualify them as cacheable.


Creating the Data Dictionary

The data dictionary is not created automatically when the database is created. The DBA has to run a series of scripts that create the data dictionary and get it ready to help with database instance operation.

Running the Catalog Scripts

The data dictionary views are created when the SYS user runs the catalog.sql script located in the %ORACLE_HOME%\rdbms\admin directory on Windows, or the $ORACLE_HOME/rdbms/admin directory on Unix.

catalog.sql is a driver script that is run as SYS. Although it is possible to run this script as anyone with SYSDBA privileges, it is not suggested to run it as anyone other than SYS because this is one of the only userids that you are never likely to delete.

  • catalog.sql Calls several other scripts that create the other data dictionary contents. The following list of called scripts provides you with an idea of what the script creates.

  • cataudit.sql Creates the AUD$ data dictionary table that tracks all the audit trail information generated by Oracle when the auditing feature of the database is used.

  • catldr.sql Creates the views used by SQL*Loader, the tool used to process large volume data loads from flat files into the database tables.

  • catexp.sql Creates data dictionary views used by the IMPORT/EXPORT utilities.

  • catpart.sql Creates views that support Oracle 9i's partitioning options.

  • catadt.sql Creates the views that support the user-defined types and object components that are part of Oracle 9i's object features.

  • standard.sql Creates the STANDARD package. The STANDARD package is used to store all Oracle scalar or simple data types. STANDARD also contains the SQL built-in functions.

It is important that you remember that catalog.sql calls these other scripts automatically. You don't have to do anything extra to have them run in your database.

Running the catproc.sql Script

catproc.sql creates the procedural options and utilities for use by PL/SQL. catproc.sql runs two different types of scripts when it is running.

If you were to examine the contents of the catproc.sql script (located in the same directory as catalog.sql), you would see references to other scripts similar to the way that catalog.sql references and calls other scripts. The scripts that catproc.sql calls, also located in the rdbms\admin directory, that end in .sql are package specifications for the many varied Oracle Server packages. These specifications contain the procedure, function, and type reference as well as constant definitions available in the package. These package specifications don't contain any actual code for the components. The scripts ending in .plb contain the actual code that is behind the procedures and functions from the specification definitions. The .plb ending, however, signifies that these package bodies are wrappered and, therefore, are unreadable by anyone except the Oracle Server.

Again, it is important that catproc.sql is run by SYS. And, again, although it is possible for any other user with SYSDBA privileges to run the script, those users could go away and the removal of the user who created the objects and packages in the data dictionary could cause the database to perform erratically.

Again, it is important that you remember that catproc.sql calls these other scripts automatically. You don't have to do anything extra to have them run in your database.


Common Views and Their Uses

In your life as a DBA, many of the data dictionary views will become some of your most useful tools. They can tell you, at a glance, what is going on in your database, and who is doing what. You will likely (and you really should) create a library of useful and much-used and relied-upon scripts to provide information out of the data dictionary. This way, you can easily get the information that you need, and you don't have to think and rethink, check and recheck the contents of the views that you are accessing to get the information you are after.

Table 5.2 provides many of the most commonly used data dictionary views, their purpose, and their meanings. In a simple, generic database, with no additional products installed, there are more than 1,200 entries in the DICTIONARY view, so an exhaustive list should be generated on your own to familiarize yourself with the kinds of information that you can glean from the data dictionary. Although Table 5.2 lists the DBA views because this exam is geared to database administrators, there are usually equivalent USER or ALL views accessible by anyone logging in to the database.

Table 5.2. DICTIONARY View Entries

Purpose

View

Description

Provide general overview

DICTIONARY

Provides descriptions of data dictionary tables and views

DICT_COLUMNS

Provides descriptions of columns in the data dictionary tables and views

Provide information relevant about user objects, such as tables, constraints, columns, and indexes

DBA_TABLES

Provides information on tables in the database

DBA_OBJECTS

Provides information on stored objects in the database such as the owner, the object name and type, and often most relevant, its status (VALID or INVALID)

DBA_LOBS

Provides description of all LOBs contained in all tables

DBA_INDEXES

Provides description of all indexes in the database

DBA_TAB_COLUMNS Also DBA_TAB_COLS

Provides information on columns of user tables, views, and clusters

DBA_CONSTRAINTS

Provides information on all constraints in the database

Provide information about users, privileges, and roles

DBA_USERS

Provides information about all users in the database

DBA_SYS_PRIVS

Provides information on all system privileges that have been granted to either users or to roles in the database

DBA_ROLES

Provides information about all roles in the database

Space allocation for database objects

DBA_EXTENTS

Provides information concerning extents

DBA_SEGMENTS

Provides information concerning segments

DBA_FREE_SPACE

Provides information concerning free space

Provide information about database structures

DBA_ROLLBACK_SEGS

Provides description of all rollback segments

DBA_DATA_FILES

Provides information about all database data files

DBA_TABLESPACES

Provides a description of all tablespaces

Provide auditing information in the database

DBA_AUDIT_EXISTS

Provides a list of audit trail entries that have been produced by AUDIT EXISTS or AUDIT NOT EXISTS

DBA_AUDIT_OBJECTS

Provides audit trail records for statements that concern objects such as tables, clusters, views, indexes, sequences, public database links, synonyms, and so on

Provide information about currently running processes

V$ views

Provides information about the current state of connections, sessions, SQL, and other active information in the database

This is by no means an exhaustive list, and you should acquaint yourself with its components. The data dictionary is one of your most powerful tools as a DBA.


Exam Prep Questions

1:

Which of the following users would you use to connect to the instance to run the scripts that create the data dictionary in the database?

  • A. SYSTEM

  • B. SYS

  • C. SYSDBA

  • D. INTERNAL

A1:

Answer B is correct. SYS is the user you connect to the database instance with in order to create the data dictionary structures. Answer A is incorrect because SYSTEM does not have, and should not be given, sufficient privileges to run the data dictionary creation scripts. Answer C in incorrect; SYSDBA is a role, not a user. Answer D is incorrect because INTERNAL, although a possible answer in previous releases, has been made obsolete in Oracle 9i.

2:

You are ready to create the data dictionary in your new database. What scripts do you run at the SQL prompt to create the data dictionary structure? [Select all that apply]

  • A. catalog.sql

  • B. data_dictionary.sql

  • C. standard.sql

  • D. catproc.sql

  • E. catldr.sql

  • F. catexp.sql

  • G. cataudit.sql

A2:

Answers A and D are correct. You run catalog.sql and catproc.sql when you need to create the data dictionary in your database. Answer B, data_dictionary.sql, is not a script that is in the Oracle system. Answers C, E, F, and G are incorrect because, although they are run to create the data dictionary tables and views, they are called by catalog.sql to do this.

3:

You are trying to figure out when the best time to create your data dictionary would be. Select the answer that best provides the most appropriate time to create it.

  • A. At the beginning of the CREATE DATABASE script

  • B. After you have created all the user tablespaces and tables in the database so you are sure that you get all that information in the data dictionary

  • C. After database creation and before giving users access to the database

  • D. After database creation and after giving users access to the database

A3:

Answer C is correct. You need to create the data dictionary after the database has been created but before you give users access to the database to make sure that anything that gets created by the users gets created and accounted for correctly. Answer A would be great; that way you always know you have it in place and you haven't forgotten anything. However, you have to have a database created in order to support the data dictionary. Answer B is incorrect because you need to have the data dictionary in place before you start creating other objects in the database. Answer D is incorrect because you could cause issues with your database if you allow users to start to create things and attempt to run transactions in the database before you have created the views and tables that are supposed to be there to help support those actions.

4:

catalog.sql creates what in relation to the data dictionary?

  • A. Tables and views

  • B. The data dictionary catalog

  • C. The packages and procedures used by PL/SQL

  • D. The system tablespace

A4:

Answer A is correct. catalog.sql creates the tables and views for the data dictionary. Answer B is incorrect because there is nothing really known as the data dictionary catalog. Answer C is incorrect; catproc.sql creates the packages and procedures. Answer D is incorrect; the CREATE DATABASE script creates the system tablespace, which houses the data dictionary.

5:

Which would contain a list of all the objects to which you, as the logged-on normal user, have access?

  • A. DBA_OBJECTS

  • B. ALL_OBJECTS

  • C. USER_OBJECTS

  • D. MY_OBJECTS

A5:

Answer B is correct. ALL_OBJECTS would give you information about all the objects to which you, as the logged-on regular user, have access. Answer A, DBA_OBJECTS, is the DBA-specific view of all the objects in the database and would provide information on all the objects to which the DBA has access (which is all the objects in the database). Answer C is incorrect because USER_OBJECTS would only give you a list of all the objects that you own. Answer D is incorrect because there is no data dictionary view by that name.

6:

What is not a synonym for the DICTIONARY data dictionary view?

  • A. CAT

  • B. CATALOG

  • C. DICT

  • D. DICTION

A6:

Answer D is correct. DICTION is not a synonym for the DICTIONARY view. Answers A, B, and C are not correct because all these are synonyms for DICTIONARY and can be used interchangeably.

7:

Who owns the data dictionary?

  • A. Oracle

  • B. SYS

  • C. The DBA

  • D. SYSTEM

A7:

Answer B is correct. SYS owns the data dictionary. Answer A is incorrect because Oracle is not a privileged user of the database, only the server system that runs the instance. Answer C is incorrect because, although the DBA manages the database, the instance, and by extension the data dictionary, she does not own the data dictionary. Answer D is incorrect because the data dictionary is housed within the SYSTEM tablespace but is not owned by the user SYSTEM.

8:

Which of the following would be a dynamic performance view in the data dictionary?

  • A. V$SESSION

  • B. DBA_PERFORMANCE

  • C. DBA_DATA_FILES

  • D. DBA_EXTENTS

A8:

Answer A is correct. V$SESSION and all the V$ views are dynamic performance views. Answer B, DBA_PERFORMANCE, is not a table or a view in the data dictionary. Answer C, DBA_DATA_FILES, provides you with information on data files in the database but is not dynamic. Answer D, DBA_EXTENTS, provides some information from which you can infer performance information, maybe, but is also not a dynamic view.

9:

Which three views would provide you with information about tables in the database?

  • A. DBA_TABLES

  • B. DBA_TABLESPACES

  • C. V$TABLES

  • D. USER_TABLES

  • E. ALL_TABLES

A9:

Answers A, D, and E are correct. Recall that for every DBA_ view, there is a corresponding ALL_ view and a USER_ view to provide different views on the same information depending on the information needed and the privileges granted. Answer B would provide information about tablespaces but not tables. Answer C, V$TABLE, might be inferred to be a dynamic performance view; however, it isn't a view in the database, and it would not provide information about tables but about their performance.

10:

If you were looking for information on what SQL statements a user was currently running in your database, what view might you look to?

  • A. V$SQLAREA

  • B. DBA_SQL_AREA

  • C. USER_SQL_AREA

  • D. ALL_SQL_AREA

A10:

Answer A is correct; in V$SQLAREA dynamic performance view, you can find currently running SQL statements in the database. Answers B, C, and D are incorrect all for the same reasons. Not only are there no views with these names that point to currently running SQL, even if there were, these types of views are not dynamic views that would capture active information like currently running SQL.


Need to Know More?

O'Reilly Press has a very good pocket reference book on the data dictionary views called, oddly enough, Oracle Data Dictionary Pocket Reference, ISBN: 0-596-00517-2.


Chapter 6. Storage Structure and Relationships

Terms you'll need to understand:

  • Table segment and table partition segment

  • Index segment and index partition segment

  • Cluster segment

  • Index organized table segment

  • Undo segment

  • Temporary segment

  • LOB segment

  • Nested table segment

  • Bootstrap segment

  • Automatic segment space management

  • Manual segment space management

Concepts you'll need to master:

  • Describe the logical structure of the database.

  • List the segment types and their uses.

  • List the keywords that control block space usage.

  • Obtain relevant information about storage structures from the data dictionary.

  • Identify the physical structure of the storage structures within the database.

  • List segment types and their uses.

  • Identify keywords controlling block space usage.

In Chapter 1, "Oracle Architectural Components," we looked at the storage structures of a database, its tablespaces and their data files. In this chapter, we continue that discussion by examining database storage, segments, extents, and database blocks.

Recall that tablespaces are made up of different segments, segments are made up of extents, and extents are made up of database blocks.


Segments

Segments are space-occupying objects in the database's data files. This means that they are associated with things that take up space, such as tables, indexes, clusters, and other similar objects.

Table Segments

Tables are the most common means of storing data within a database. A table's segment stores the data for a table that is neither a cluster table nor a partitioned table. Data within the segment is stored in no particular order, a situation that the database administrator (DBA) has little control over. DBAs can't control the location of rows within the blocks within the segments in the table. All the data within a table segment must be stored within a single tablespace.

Table Partition Segment

Because scalability, maintainability, and availability are primary concerns in a database, particularly when a given table reaches either an extremely large number of rows, or an inordinate number of concurrent usage, a table can be partitioned, with data from that single table residing in several partitions, each in its own tablespace. If a table is partitioned, each partition is a segment. This means that storage parameters can be specified for each individual partition independent of each other.

Partitioning, and therefore this type of segment, is only available with the Oracle 9i Enterprise Edition.

Cluster Segments

A cluster, somewhat like a table, is also a type of data segment. Rows in a table that is a member of a cluster are based on a key column's values. All the tables in a cluster belong to the same segment and therefore share that segment's storage characteristics. To access the rows in a cluster, you need to use either an index or a hashing algorithm.

Index Segments

Each index on a table has its own single index segment. Its purpose (the index and the segment) is to look up the location of the referenced rows in the table based on a key value. It is important to remember that index segments can be, and usually should be, in different tablespaces than the table segments with which they are associated.

Index-Organized Table

An index-organized table (IOT) stores data within the index based on the key value. An IOT doesn't need a table against which to look up the values because all the data is retrieved directly from the index.

Index Partition

Indexes can be partitioned and spread across several tablespaces just like tables can. The primary reason to partition indexes is to distribute index I/O. Again, as with table partitioning, the option requires the use of Oracle 9i Enterprise Edition.

Undo Segment

Undo segments are used by transactions making changes to the database to store the information necessary to undo the changes that they are making. Before the change is made, the old values are stored to the undo segments allowing the changes to be undone.

Temporary Segment

Oracle wisely tries to perform sorting operations in memory if they can be processed there because memory is faster than disk access. Sorts are done any time a user creates an index, selects distinct values from tables, selects with an order by or group by clause, and many other times. But if a sort needs more space than is available in memory, the intermediate results of the sort are stored to disk temporarily. These results are stored in temporary segments.

LOB Segment

Large Objects Binary (LOBs) can be used in Oracle to store, in a table column, objects larger than could fit in any other kind of column. It can store text documents, video, audio, images, and so on. The Oracle Server stores these values not in the segment with the rest of the tabular data, but rather in separate segments known as LOB segments. The table, and therefore the table's segment, stores only the locator pointer to the location of the referenced LOB data. LOB segments can, and usually should, be located in different tablespaces than the table segment with which they are associated.

Nested Table Segment

A user-defined table can be stored as a single column in another table. The user-defined pseudo-table, or nested table, can store things such as items in an order, address lines in an address, or payments made on an insurance claim among other things. In this way, one row/column combination can be used to store several columns and several rows that correspond to the row's key all within that single outer row. The inner, nested table is stored within a separate segment from the outer table's segment.

Bootstrap Segment

The bootstrap, or cache, segment is created when you create the database when the Oracle Server runs the sql.bsq script. This segment initializes the data dictionary cache when the database is opened by the instance. This segment can neither be queried nor updated and requires no maintenance (my favorite kind of segment!).

Recall that a segment is made up of extents. You can specify a storage clause to specify at the segment level how to control the ways that the extents are allocated.

Storage parameters set at the segment level override any of those same parameters that have been set at the tablespace level except for the minimum extent size or uniform size tablespace parameter. If the parameters aren't set at the segment level, they default to the tablespace level parameter values, and if not set at that level, they default to the Oracle Server's system level default values.

It is important to remember that the default values are set extremely low. The storage parameters, therefore, should be set at least at the tablespace level or at the segment level.

If the storage parameters are altered after the creation of the segment, the new values apply only to those extents not yet allocated to the segment.

There are parameters that cannot be specified at the tablespace level and therefore should be specified at the segment level.


Extents

Extents are allocated to a segment when that segment is created, extended, or altered. They are deallocated when the segment is dropped, altered, or truncated.

When a tablespace is created, data files associated with that tablespace contain a header, the first block, or set of blocks, in each data file. Whenever a segment gets created, it is allocated space from the tablespace's free extents. The contiguous space being used by a segment is referred to as used extents. If the segment releases space, extents that are released are added to the pool of free extents available to the tablespace to be allocated to any segment associated with that tablespace.


Database Data Blocks

Remember, the data block is the minimum unit of I/O in the database instance. Each database data block consists of one or more operating system blocks, and the block size of a tablespace is set at the time of tablespace creation. DB_BLOCK_SIZE is the default block size for all database data blocks.

Blocks can be managed using either automatic segment space management or manual space management.

Automatic Segment Space Management

In automatic segment space management (ASSM), the job of managing free space is taken care of within the database segments themselves. Tracking of the segment's free and used space is done using bitmaps (which I'll explain in a moment) rather than using FREELISTS. ASSM allows for more ease of management, better space utilization, and better performance for concurrent Insert operations.

FREELISTS are the constructs that Oracle uses internally to determine whether any free space is available in any given block that can be used for inserts. When this information is stored in the data dictionary, it takes a call to that view to determine where each insert should be placed any time there is an insert operation. With ASSM, and having all the information stored in a bitmap for any given data block, Oracle can save a query to the data dictionary and can determine when the insert happens which blocks contain sufficient space for the inserted data to be held.

The only situation where automatic space management is not applicable is in the case of a table that contains LOBs.

ASSM helps to better utilize space in the database with all objects, particularly those with greatly varying row sizes, utilizing available space more efficiently. Furthermore, because ASSM can make runtime adjustments to variations in concurrent accesses, concurrency handling is improved.

Bitmap segments inside the data and index segments contain bitmaps, which describe the status of each block in the segment with regard to available space in the blocks. This map is located in a separate set of blocks in the segment known as bitmapped blocks (BMBs). Whenever you insert a new row, the server searches this map for an available block that has sufficient space to hold the new data. As the amount of available space inside the blocks changes, the new states are reflected in the bitmap.

ASSM can be enabled only at the tablespace level, for what is referred to as locally managed tablespaces. After the tablespace is created, the specifications apply to all the segments that get created in that tablespace. A sample creation script would be similar to the following:

CREATE TABLESPACE userdata02
DATAFILE '/mydatabases/mydb1/userdata02.dbf' SIZE 100 M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 32K
SEGMENT SPACE MANAGEMENT AUTO;

The creation of the bitmapped segments is inferred by the SEGMENT SPACE MANAGEMENT AUTO clause of the CREATE TABLESPACE command. When this happens, it cannot subsequently be altered by specifications of PCTUSED, FREELIST, or FREELIST GROUPS parameters.

Heap tables (typically simply called tables), indexes, and index-organized tables can all be bitmap managed.

Manual Segment Space Management

Manual segment space management tells Oracle that you intend to use the free lists for managing the free space within segments and allows you to configure the storage parameters manually. These parameters include PCTFREE, PCTUSED, and FREELIST. This used to be the only way that tablespaces and their storage could be managed.

With this method, you have considerably more control. You can control how the block space is configured and used. You can, further, control when block space is made available.

CREATE TABLESPACE userdata02
DATAFILE '/mydatabases/mydb1/userdata02.dbf' SIZE 100 M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 32K
SEGMENT SPACE MANAGEMENT MANUAL;

If not specified as AUTO, segment space management is MANUAL by default.

The next section explains how space within a block is managed for a data segment that is dictionary managed and has a setting of PCTFREE=10 and PCTUSED=40.

Block Space Usage

Rows are inserted into the block whenever necessary until the freespace in the block is equal to or less than 10% (it may not be possible to have a transaction stop at exactly 10% free space). This block is now no longer made available for inserts (rows at this point are taking up at least 90% of the available data area or 100% PCTFREE plus or minus).

The space that remains can be used for row size expansion from updates. If a column that was null now contains data, or a column that was varchar2 (60) had 20 characters but now has 55, these would go toward filling up the extra 10% of the data block.

If rows are deleted, and enough rows are deleted from the block, or if the rows decrease in size as a result of other updates, the block's utilization may fall below 90%. However, this only means that there is additional space for updates, not that any more inserts will occur to that block. Inserts will not occur until the utilization of that block falls below the value of PCTUSED, which in this case is 40%.

If utilization does fall below 40%, the block is again made available for inserts. As rows are inserted into the block, utilization again increases, and the vicious circle starts again.

Data Block Layout

The block contains a header, free space, and data:

  • Header Contains the address of the data block, a table directory, row directory, and transaction slots used whenever a transaction, or transactions, make changes to rows in the block. These headers grow from the top of the block down. The block header can be further broken down into the following subsections

    • Common and variable header Contains the general block information, its address, and type of segment to which it belongs.

    • Table directory Contains information about the table that has its rows in the given block.

    • Row directory Contains information about the rows in the block including the addresses for each row piece in the row data portion of the data block.

  • Free space Found in the middle of the block, between the header and the data space. This allows the header space to grow down when necessary and the data space to grow up when necessary. The free space in a data block is contiguous when the block is first defined, but with deletions and updates, may become fragmented. The free space in the data block are automatically coalesced by Oracle Server whenever it becomes necessary.

  • Data space When data is inserted into the segment to which the extent belongs, the data is inserted into the corresponding extent database blocks from the bottom up.


Block Utilization Parameter

Block space utilization parameters can be used to control the space usage in index and data segments.

INITRANS

INITRANS specifies the initial number of transaction slots created in index or database blocks. The transaction slots are used to store the information about the transactions actively making changes to the block at a point in time. Any transaction uses only one transaction slot in a data block regardless of the number of rows or index entries being made by the transaction.

INITRANS defaults to 1 for data segments' database blocks, and 2 for index segments. This guarantees a minimum level of concurrency. If necessary, additional transaction slots can be allocated for the free space in the data block to allow for more concurrent transactions to modify data in the block.

MAXTRANS

MAXTRANS specifies the maximum number of transaction slots created in an index data block or a database data block. The default setting for MAXTRANS is 255, meaning that 255 concurrent transactions can be allowed for each given data or index data block. If this parameter is set, it restricts the use of space for transactions slots, therefore guaranteeing that there is sufficient space in the block for use by row and index data.

PCTFREE

PCTFREE, or percent free, for a data segment specifies the percentage of space in each data block that is reserved for any growth that results from updates to rows within the block. The default, for dictionary-managed tablespaces, is 10%. This parameter, if set, in a locally managed tablespace is ignored.

PCTFREE is calculated as a percentage of the available data space or block space remaining after deducting header space from the total block size.

PCTUSED

PCTUSED, or percent used, in a data segment represents the MINIMUM percentage of used space that Oracle tries to maintain for each block of the table's segment. A data block is placed back onto the free list when the used space falls below the PCTUSED threshold.

A free list is a list of blocks that are candidates for future inserts. Any given segment is created with one free list, although a segment can be created with more by setting the FREELISTS parameter of the storage clause.

FREELISTS are covered in detail in the Oracle 9i Performance Tuning exam.

The default setting for PCTUSED is 40% and, like PCTFREE, is ignored if set in a locally managed tablespace.

PCTUSED is calculated as a percentage of the available data space or block space remaining after deducting header space from the total block size.


Storage Structure Information in the Data Dictionary

The interrelation between the tablespaces, their data files, segments, and free and used extents can be examined by querying the data dictionary. The views that you can use to find information on tablespace are in the following sections.

DBA_TABLESPACES

When a tablespace with one or more files is created, a single row is created in DBA_TABLESPACES. This view provides information that allows you to determine the status, type, and space usage of the tablespace.

DBA_DATA_FILES

For every single file associated with a tablespace in the database, online or offline, a row is added to DBA_DATA_FILES. The following query can be used to find information on the data files associated with the tablespaces in the database:

SELECT FILE_NAME, TABLESPACE_NAME, BYTES, BLOCKS
FROM DBA_DATA_FILES
where tablespace_name = 'UNDOTBS1';

The following shows the output of the query:

TABLESPACE_NAME | FILE_NAME | BYTES | BLOCKS
UNDOTBS1 | /mydatabases/mydb1/undotbs01.dbf | 209715200 | 51200

DBA_SEGMENTS

Whenever a segment is created, regardless of the segment type, a row is added to the DBA_SEGMENTS view. From this view, you can determine the number of blocks associated with a segment, the number of extents, to what tablespace the segment belongs, and more.

To obtain information on the number of extents and blocks allocated to a segment, you would execute the following query:

SELECT SEGMENT_NAME, TABLESPACE_NAME, EXTENTS, BLOCKS
FROM DBA_SEGMENTS
WHERE OWNER = 'SCOTT';

Here is the output you would expect to see from running this query.

SEGMENT_NAME | TABLESPACE_NAME | EXTENTS | BLOCKS
DEPT | SYSTEM | 1 | 16
EMP | SYSTEM | 1 | 16
BONUS | SYSTEM | 1 | 16
SALGRADE | SYSTEM | 1 | 16
PK_DEPT | SYSTEM | 1 | 16
PK_EMP | SYSTEM | 1 | 16
6 rows selected |  |  |

DBA_EXTENTS

Whenever space is allocated the extents of a segment, that space can be viewed in the DBA_EXTENTS view. Because the extent is the smallest unit of space allocated (although the block is the smallest unit stored or retrieved), whenever an additional extent is allocated to a segment, information about that extent can be found in DBA_EXTENTS.

If you want to get information on the number of blocks and extents for a given segment from this view, you can run the following query:

SELECT EXTENT_ID, FILE_ID, BLOCK_ID, BLOCKS
FROM DBA_EXTENTS
WHERE OWNER = 'SCOTT'
AND SEGMENT_NAME = 'EMP';

EXTENT_ID | FILE_ID | BLOCK_ID | BLOCKS
0 | 1 | 82177 | 16

DBA_FREE_SPACE

When a tablespace and its data files are added to the database, but before anything is inserted into the objects, all the space in each data file minus the space allocated to the file header, shows up in the DBA_FREE_SPACE view.

When extents are added to a segment, and that space is viewed in DBA_EXTENTS, the space found in DBA_FREE_SPACE is adjusted lower to show the reduced free space in the files where the extents were created for the segment.

All the space in a file, with the exception of that space allocated to the file's header block, must be accounted for in either DBA_FREE_SPACE or DBA_EXTENTS.

DBA_FREE_SPACE is used to check the extents from a given segment.

SELECT TABLESPACE_NAME, COUNT(*), MAX(BLOCKS), SUM(BLOCKS)
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME;
TABLESPACE_NAME  COUNT(*)  MAX(BLOCKS)  SUM(BLOCKS)

The following is the output that you might see if running this query.

TABLESPACE_NAME | COUNT | MAX(BLOCKS) | SUM(BLOCKS)
EXAMPLE | 1 | 2640 | 2640
INDX | 1 | 6384 | 6384
SYSTEM | 1 | 17120 | 17120
TOOLS | 1 | 126448 | 126448
UNDOTBS1 | 11 | 35568 | 45680
USERS | 1 | 6384 | 6384
XDB | 1 | 2800 | 2800


Exam Prep Questions

1:

Which data dictionary view would you use to get a list of all tablespaces and their associated data files?

  • A. DBA_TABLESPACES

  • B. DBA_DATA_FILES

  • C. DBA_SEGMENTS

  • D. DBA_EXTENTS

A1:

Answer B is correct. DBA_DATA_FILES gives you the TABLESPACE_NAME and its associated FILE_NAME as well as the numbers of bytes and blocks in the file and other useful information.

Answer A is incorrect because DBA_TABLESPACES gives you the TABLESPACE_NAME but not the filenames associated with it. Answer C is incorrect because it gives you segment information, and answer D is incorrect because it gives you extent information but not tablespace or data file information.

2:

Extents are collections of __________________.

  • A. Database blocks

  • B. Tablespaces

  • C. Table segments

  • D. Data files

A2:

Answer A is correct. Extents are composed of database blocks. Answer B is incorrect; tablespaces are the highest level of physical storage in the database. Answer C is incorrect; a table segment is made up of extents. Answer D is incorrect; a data file contains extents, not the other way around.

3:

What is the default number of transactions that MAXTRANS is set to if not specified?

  • A. 255

  • B. 10

  • C. 40

  • D. 1

A3:

Answer A is correct; the default MAXTRANS setting is 255. Answer B is incorrect; that is the percent that PCTFREE is set to by default. Answer C is incorrect; that is the PCTUSED default value. Answer D is incorrect; it is the default number for INITRANS.

4:

In a tablespace that has automatic segment space management, where is the free space managed?

  • A. In the data file

  • B. In the extent

  • C. In the data dictionary

  • D. In the bitmap segment

A4:

Answer D is correct. Bitmap segments inside the data and index segments control how free space is controlled in the segments. Answer A is incorrect because the data file is a repository for other structures and doesn't really contribute to space management. Answer B is incorrect because the extent doesn't manage space at the segment level, it only makes up a segment. Answer C is incorrect; one reason to use automatic segment space management is to limit the bottlenecks on the data dictionary.

5:

What does the parameter INITRANS specify?

  • A. The initial number of transactions created when a user logs in to SQL Plus

  • B. The maximum number of transaction slots that can be created for index and database blocks

  • C. The initial number of transaction slots created for index and database blocks

  • D. The initial number of transactions that can be run in the instance

A5:

Answer C is correct. INITRANS is the minimum number of transactions slots created for index blocks (default 2) and database blocks (default 1). Answer A is incorrect; there is a one-to-one correlation between transactions and SQL Plus sessions. Answer B is incorrect; MAXTRANS is the parameter that specifies the maximum number of transaction slots created in the database block. D is incorrect; no initial transactions are started when the instance is running.

6:

Which is not part of the database block header? [Choose all that apply]

  • A. Address of the database block

  • B. Address of the database

  • C. Address of the senior DBA

  • D. Row directory

  • E. Table directory

  • F. Transaction slots

  • G. Free space

  • H. Data space

A6:

The correct answers are B, C, G, and H. The address of the database (B) is not housed anywhere. The address of the senior DBA (C) is not likely to be kept in most databases and isn't stored at the database level. Free space (G) is a part of the block, but not of the block header. Data space is a part of the block, but not of the block header. Address of the database block (A) is in the header, as are the row directory (D), table directory (E), and transaction slots (F).

7:

When is an extent allocated to a segment? [Select all that apply]

  • A. When the segment is created

  • B. When the segment is opened

  • C. When the segment is truncated

  • D. When the segment is deleted

A7:

Answer A is correct. Extents are allocated when a segment is created, extended, or altered. Answer B is incorrect because segments are not opened; databases are opened. Answer C is incorrect because only tables and clusters can be truncated. Answer D is incorrect; when a segment is deleted, the extents are freed, not added.

8:

What information can be gained from querying the bootstrap segment?

  • A. When the database cache was created.

  • B. When the last maintenance data was for the bootstrap segment.

  • C. What segment types are found in the given database.

  • D. None, the bootstrap segment can't be queried.

A8:

Answer D is correct. The bootstrap segment can't be queried. Answer A is incorrect because, although the bootstrap segment helps create the database cache when the database is opened by the instance, it cannot be queried. Answer B is incorrect; you can neither query nor maintain the bootstrap segment. Answer C is incorrect; DBA_SEGMENTS can be queried to determine the kinds of segments located in the database.

9:

Which is not a part of the database block?

  • A. Header

  • B. Row directory

  • C. Data

  • D. Freelists

A9:

Answer D is correct. FREELISTS is a parameter that can be specified to help with space management but are not themselves located in the block. Answer A is incorrect because each database block contains a header. Answer B is incorrect because the row directory is a part of the header. Answer C is incorrect because the data is a part of every block regardless of the type of segment to which it belongs.

10:

Which is more appropriate to use to store a small list of values in a single column in each row in your address table?

  • A. VARRAY

  • B. Nested table

  • C. Index organized table

  • D. Index

A10:

Answer A is correct. You would store a limited list of values as a single column in each row of a table as a VARRAY. Answer B is incorrect; nested tables are useful for storing an entire row from another pseudo-table as a column in a row in your address table. Answer C is incorrect; you cannot store an index organized table within another table. Answer D is incorrect; indexes assist with retrieving information for a table but are not stored within the table.


Need to Know More?

To learn more about the Oracle storage structures, you can read the Oracle 9i concepts manual at http://tahiti.oracle.com.


Chapter 7. Globalization Support

Terms you'll need to understand:

  • National Language Support

  • NLS

  • Language support

  • Territory support

  • Character set support

  • Linguistic sorting

  • Message support

  • Date and time formats

  • Numeric formats

  • Monetary formats

Concepts you'll need to master:

  • Choose database character set and national character set for a database.

  • Specify language-dependent behavior using initialization parameters.

  • Specify language-dependent behavior using environment variables.

  • Specify language-dependent behavior using the ALTER SESSION command.

  • Use different types of National Language Support parameters.

  • Explain the influence on language-dependent application behavior.

  • Obtain information about global support usage from the database.

We live in an increasingly global society. To keep up with what is going on in business today, Oracle has added increased globalization support to its offerings standard with its database.

This chapter takes a look at what globalization includes in the Oracle 9i database.


Globalization Support

For Oracle, globalization support means the assurance that database utilities, error messages, dates, times, monetary information, sort orders, numbers, and calendar conventions automatically adapt to the native language for the location where the access is occurring.

Oracle currently supports more than 55 different languages in nearly 90 territories, 84 different linguistic sorts, and 235 different encoded character sets. This means that there are possibilities for reaching nearly any user, client, or customer in nearly any location in the world in their native language.

The language-dependent operations in Oracle are controlledyou guessed itby a number of parameters and environment variables both on the client machine and on the server. This is because the server may not be running in the same location, or the same part of the world as the client is running. But regardless of where the two pieces are, if they are using different character sets, the Oracle server can handle the character set conversions automatically and transparently to the user.

Users can interact with the database and store, process, and retrieve data in their native language. Different countries often dictate different cultural conventions that may directly affect the formatting of data. This includes but is not limited to different character sets and custom sort orders for different languages and locations.

Date and time formats can be expressed to the user either according to ISO conversions for years, months, days, hours, minutes, seconds, and fractions of sections, or time zone regions can be used to support things such as Daylight Savings Time in the US. Different calendar formats can be used to present accurate data to the user in her own calendar conventions such as Gregorian, Japanese, Imperial, and Thai Buddha.

Numerical data can be presented to users in the local format they are used to. This can extend to the use of the "," or the "." character as the separation character in a number string.

Currency symbols that reflect the local economy and ISO conventions as well as credit and debit symbols for accounting also can be customized based on different locations.

Let's continue by looking at the database character sets and encoding schemes.


Character Sets and Encoding Schemes

Oracle supports not only 8-bit but also 7-bit schemes for single-byte character sets. It also supports fixed-width multibyte character sets as well as varying-width multibyte character sets.

An encoding scheme for a character set specifies the numeric codes that correspond to the characters that the computer or terminal can display and receive. These encoding schemes are used to interpret the data into symbols that are meaningful to the users reading the data from the terminal or the machine from which they are reading the characters.

To this end, Oracle offers different classes for encoding schemes, including single-byte schemes, varying-width multibyte schemes, and fixed-width multibyte schemes and Unicode schemes.

Single-Byte Character Sets

In single-byte character sets, each character occupies exactly one byte of storage.

Single-byte, 7-bit encoding schemes can be used to define up to 128 characters (2 to the 7th power characters). The US7ASCII 7-bit character set corresponds to the ASCII 7-bit American character set.

Single-byte, 8-bit encoding schemes can be used to define up to 256 characters (2 to the 8th power characters). Several 8-bit character sets can be used in this representation. ISO 8859-1 Western European is represented by the WE8ISO8859P1 character set in Oracle. EBCIDIC Code Page 500 8-bit Western European is represented by the WE8EBCIDIC500 character set. DEC 8-bit Western European is represented by the WE3DEC character set.

Varying-Width Multibyte Character Sets

Varying-width multibyte character sets are represented by one or more than one byte per character. These multibyte character sets are typically used to store Asian languages and to support operations based on those languages. Many of these multibyte character sets use the most significant bit of each byte to store the information on if the byte represents an entire character, or if it is part of a multibyte represented character; others differentiate the single byte from multibyte characters in other ways.

Examples of varying-width multiple byte schemas include the following:

  • Japanese Extended Unix Code

  • Chinese GB2312-80

  • AL32UTF8

AL32UTF8 is a varying-width multibyte character set.

Fixed-Width Multibyte Character Sets

Fixed-width multibyte character sets provide database support similar to the varying-width multibyte character sets in that they allow for the storing of characters in more than one byte. The difference is that every character, regardless of how many bytes the character really takes up, takes up 2 bytes of storage space. This allows for the benefit of having a uniform byte size and ease in calculating sizes more exactly. Only one fixed-width multibyte character set is supported, and it is the AL16UTF16.

AL16UTF16 is a fixed-width multibyte character set.

Unicode Character Set

Unicode is a global character encoding standard that represents all characters for computer usage, including technical symbols and characters used in publishing. The current standard, version 3.0 of the Unicode standard, contains 49,149 characters while providing the capability for extending to more than a million different characters.

Characters in the Unicode character sets can have their characters represented in several different encoding formats.

Unicode characters can be represented in a number of different ways, using several different encoding schemes. UTF-16, or Universal Character Set Transformation Format is a 2-byte, fixed-width format. UTF-8 is a multibyte, varying-width format. To take advantage of these two standard formats, Oracle provides AL32UTF8, UTF8, and UTFE as database character sets and AL16UTF16 and UTF8 as national character sets. The advantage of using UTF-8 based character sets is that they include ASCII standard characters, implemented using the same single-byte encoding. Because the UTF8 character set is a superset of ASCII, the migration of database character sets is easier if you are upgrading ASCII-based character sets to Unicode character sets.

Be careful with the difference between UTF-8 (with a hyphen) and UTF8 (without a hyphen). UTF-8 refers to the Unicode standard, and UTF8 refers to the Oracle character set based on the Unicode standard.

The Unicode standards provide an absolutely unique code value for every character, regardless of the platform on which the system is running, the program that is running, or the language that the data is stored in or accessed with. Many software vendors and hardware vendors have adopted the Unicode standard. Many operating systems and browsers now support Unicode, which is required by many other current standards (such as XML, Java, JavaScript, and LDAP) and is also compatible with the ISO/IEC 10646 standard. Oracle has supported Unicode character sets as far back as Oracle 7 and continues to support it today. Oracle 9i's support of the Unicode standard has expanded greatly.

UTF-8 is the 8-bit encoding of Unicode. It is a variable-width multibyte encoding scheme wherein many of the character codes have the same meaning as those same codes in ASCII.

UTF-16 encoding is the 16-bit encoding of Unicode. It is a 2-byte, fixed-width encoding scheme that allows many of the character codes to have the same meaning that the same codes have in ASCII.

Two different types of character sets are of concern to DBAs. The first is the database character set, and the second is the national character set. The following sections discuss these character sets and their differences.


Database Character Set

Database character sets are used by Oracle for storing data in the data types CHAR, VARCHAR2, CLOB, and LONG (including the columns referenced in the data dictionary). It is the data set used for identifiers for things such as table names, index names, column names, and PL/SQL variable names, and for entering SQL commands and entering and storing PL/SQL source code. It is the character-encoding scheme used by the database that was defined in the CREATE DATABASE statement.

After the database is created, you cannot change the database character set without re-creating the database. It is therefore important that you consider the character set that you want to use. The following is a list of questions to consider when you are deciding what database character set to define at database creation time:

  • What primary languages does the database need to support?

  • What languages do you foresee the database needing to support in the future?

  • Is the character set that you want to use available on the operating system (this speaks to ASCII versus EBCIDIC)?

  • What character sets will be used on the majority of the clients?

  • If you are implementing a specific application that this database will support, how well does the given application handle the character set?

  • Are there any performance implications of the character set?

  • Are there any significant restrictions to you or your company's business that can be associated with the character set?

  • Are you going to need the ability to display special characters (such as S or b, m or p) that are to be stored in the database?

  • Are there any interoperability concerns with system resources on the machine that will host the database or with any of the applications that will use it as a back end?

Several different character sets may meet the needs that are determined by the answers to questions such as these. But you should consider not only the needs that you have, as an organization, at the time that the database is built but also how those requirements might change in the future. Choosing the database character set with the widest range of possibilities and that still includes the requirements that you have when you are building the database is the best bet. It eliminates the need, down the road, for migration to a different character set.

Because the database character set is used to identify and store SQL and PL/SQL source code, it must have either an EBCIDIC or 7-bit ASCII as one of its subsets. This is because of the different architectures of the operating systems on which the Oracle database can reside. For this reason, it is not possible to have a fixed-width multibyte character set as a database character set, only as a national character set.

It is not possible to have any fixed-width multibyte character set as the database's database character set. Only the national character set can be a fixed-width multibyte set.

Although the database maintains and processes the actual database character set, you must depend on other resources from the operating system for your database and instance to function optimally.

The operating system supplies the fonts that correspond to the character set that you have chosen (both the client operating system and the server operating system, if these are different platforms). It is possible for Oracle to convert the operating system's character set into the database's character set (and vice versa). If you happen to choose a character set different from what is available on the operating system, you should remember that overhead goes along with this character set conversion. Make sure that the operating system has characters in its character set equivalent to any of the special characters that you might store in the database so that no data is lost in the conversion.

Performance implications can accompany the decision you make, too. For best performance, you should choose, if possible, a character set that will mean that no conversions are necessary at the operating system level. Single-byte character sets are more optimal for performance than are multibyte character sets (they are also the most efficient in terms of storage space requirements) but do limit the number of languages that you can use.

Now that we have looked at the database character sets and what those bring to your environment, let's look at an alternative to this character set, the National Character Set.


National Character Set

National character sets are alternative character sets that allow you to store Unicode character data that does not have a comparable Unicode database character set. This is only one of the reasons to consider a different national character set from the database character set. Others include differences in properties that have a different character-encoding scheme that might be more desirable for extensive processing operations and ease of programming in the chosen national character set.

Oracle has provided the NCHAR, NVARCHAR2, and NCLOB data types in the Unicode encoding schemes.

NCHAR, NVARCHAR2, and NCLOB are the only data types that Oracle 9i has that are Unicode compliant.

Table 7.1 provides information on the differences between database character sets and national character sets.

Table 7.1. Database and National Character Set Characteristics

Database Character Sets

National Character Sets

Defined at database creation time

Defined at database creation time

May not be changed without re-creation of the database,with limited exceptions

May not be changed without with re-creation of the database, limited exceptions

Stores data in columns of type LONG, CHAR, VARCHAR2, and CLOB

Stores data in columns of type NCHAR, NVARCHAR2, and NCLOB

Can store varying-width character sets

Can store Unicode using either the AL16UTF16 or UTF8 character sets

There are only two choices for national character setsUTF8 and AL16UTF16. When making the decision as to which to use, you need to determine whether either space or performance is expected to be an issue. You may not be able to make this determination at this point, but you should hazard the best guess you can to make the best decision.

AL16UTF16 stores characters in a fixed-width, 2-byte manner. UTF8 is a variable-width character set and stores its characters in exactly 2 bytes.

UTF8 provides more options and flexibility than AL16UTF16 but also has characteristics that make it often less desirable. UTF8 takes up more space than does AL16UTF16, and is also less efficient in terms of performance (this is because AL16UTF16 is fixed width and always takes up 2 bytes).

Should You Use Unicode?

Okay, so Unicode character set schemes are a great thing, but when should you use them? What are the advantages of implementing a Unicode character set? The following sections discuss some of the advantages of using a Unicode national character set.

Ease of Migration

With a Unicode character set, you have easier code migration for Java and PL/SQL code and to and from ASCII-based data. Minimal changes are necessary when implementing multiple languages in a multinational database. This is because with Unicode, when you have to deal with Java and PL/SQL code and are storing multiple languages in existing SQL CHAR data types, you don't need to recode your programs to use the NCHAR data types. This means less recoding and more reusability. Also, if your current data set is strictly US7ASCII, the database can be migrated with a simple ALTER DATABASE statement to use a Unicode character set.

Data Distribution

With a Unicode character set, multilingual data is more evenly distributed. If you have multilingual data, and that data is distributed throughout your database, the choice of Unicode as a national character set solution means that you do not have to identify what columns might be storing multilingual data.

InterMedia Text Search

Unicode character sets facilitate InterMedia Text search. If you have multilingual data in your database, and you are storing it in BLOBs accessed by Oracle text, your only solution is to use a Unicode character set to allow for the InterMedia Text search on that data.

Incremental Addition of Multilingual Support

If you already have an existing database with a database character set that constrains the number and kind of multilingual languages that you can easily store in the database, you can use Unicode to add functionality for these languages without having to migrate the database. After you have added Unicode functionality, you can add the NCHAR data types to new tables and to existing tables in your database.

Creation of Packaged Applications

You can use the NCHAR data type behind many packaged applications because it is a reliable Unicode data type that allows data to be always stored in Unicode standards with length of the data always specified in the UTF-16 code units. Because of this, you would only need to test an application once on a database with Unicode standards and Unicode data types and be assured that the application will run on a customer's database regardless of what database character set the customer has implemented.

Performance

Remember, for performance concerns, you might consider a single-byte character set for the database character set, but if you require the ability to support multiple languages in the database, you can provide the functionality that you need with the AL16UTF16 for the multilingual data and still provide the best performance. There is performance overhead when your database uses UTF-8 encoding. This overhead deals with the fact that you have variable-width format.

There are performance gains to be seen in fixed-width, single-byte or fixed-width, multibyte character sets. The fixed nature means that Oracle always knows exactly how many bytes a character will consume, and fetches will be more efficient.

Many data behaviors are language dependent. These behaviors and the means to deal with them and control how your database deals with them are discussed in the following sections.

Now let's look at what kind of language-dependent behavior we can expect to see in relation to Oracle 9i and globalization.


Language-Dependent Behavior Specification

To specify how the database will act and react to language-dependent actions, it is important to have a method of control over the way the database will behave under given conditions. These behaviors are wide and varied but are controlled in three simple ways: initialization parameters, environment variables, and the ALTER SESSION command.

Initialization Parameters

There are two primary initialization parameters (each with its own subparameters) that you can use to assist you with different ways that your database will deal with different aspects of multilingual actions. These are NLS_LANGUAGE and NLS_TERRITORY.

NLS_LANGUAGE

The NLS_LANGUAGE parameter provides you with the ability to specify the way that language will be handled in messages, day and month names, month abbreviations, and symbols that are date and time related (for example, A.D., B.C., a.m., and p.m.). It also controls the default sorting mechanism for character data. If not specified otherwise, NLS_LANGUAGE defaults to AMERICAN. NLS_LANGUAGE has two subparameters:

  • NLS_DATE_LANGUAGE explicitly changes the language used for day and month names and their abbreviations and for the spelled-out values for other date format elements. This parameter defaults to AMERICAN.

  • NLS_SORT gives you the ability to change the linguistic sort sequence that Oracle uses to sort character data values. The valid values for this parameter must be the name of a linguistic sort sequence. NLS_SORT defaults to BINARY.

NLS_LANGUAGE determines the default values for NLS_DATE_LANGUAGE and NLS_SORT.

NLS_TERRITORY

The NLS_TERRITORY parameter allows you to control day and week numbering, the default date format, the decimal character, group separator, and the default ISO and local currency symbols for your database.

NLS_TERRITORY has the following subparameters:

  • NLS_CURRENCY allows you to explicitly specify a new local currency symbol. NLS_CURRENCY defaults to "$".

  • NLS_ISO_CURRENCY allows you to explicitly specify the territory whose ISO currency symbol should be used. NLS_ISO_CURRENCY defaults to AMERICA.

  • NLS_DATE_FORMAT allows you to explicitly specify the new default date format, and the value must be a date format model. NLS_DATE_FORMAT defaults to DD-MON-RR.

  • NLS_NUMERIC_CHARACTERS allows you to explicitly specify a new decimal character and group separator character. NLS_NUMERIC_CHARACTERS defaults to "." for the decimal indicator and "," for the group separator.

  • NLS_DUAL_CURRENCY supports the euro. In January 1999, the new currency for the European union, known as the euro, made its world debut. To extend support for this new currency, Oracle added dual currency support. The new initialization parameter associated to this new support is the NLS_DUAL_CURRENCY. NLS_DUAL_CURRENCY sets an alternative currency symbol for the user session.

The following territories have the euro symbol added for dual currency support: Austria, Italy, Belgium, Luxembourg, Denmark, Netherlands, Finland, Portugal, France, Spain, Germany, Sweden, Greece, United Kingdom, and Ireland.

The ISO character sets have specified code points for the euro symbol. These settings are all enabled at the session level (meaning that they are dynamic initialization parameters) and, therefore, provide you the flexibility to allow for the storage of information from France at the same time as you are allowing data to be accessed and stored from Greece, Germany, Spain, and the United States.

Okay, but how do we set these parameters with environment variables?


Setting Environment Variables

Recall that on the Unix platform, NLS_LANG is an environment variable, and on Windows it is set globally in the Registry, although you can override it by setting the NLS_LANG local environment at your command prompt. NLS_LANG controls the languages used for Oracle messages, day and month names, the default date format, the decimal character and group separator, the local currency symbol, and the week start day.

Working with NLS_LANG

The format for setting the NLS_LANG environment variable is as follows:

NLS_LANG=language_territory.characterset

Or with the values filled in for each of the parameters:

NLS_LANG=FRENCH_CANADA.WE8ISO8859P1

The "language" portion of the language_territory overrides the default values of NLS_LANGUAGE and controls the same features that NLS_LANGUAGE controls (Oracle messages, sorting, day and month names, for example). If the language portion is not specified, it defaults to AMERICAN.

The territory portion of language_territory overrides the default value of NLS_TERRITORY and controls the same features that NLS_TERRITORY controls (default date, monetary, and numeric formats). If this value is not specified, it is derived from the language value.

The characterset portion of the example specifies the character-encoding scheme used by a client application. This application is typically running at the user's terminal. For every supported character set, a unique acronym is associated to it, and each language has a default character set associated to it.

You create the database with the CHARACTER SET <character set> parameter and the NATIONAL CHARACTER SET <national character set> parameters. Then on the client you can set the environment variables that allow for that client's session to take on the different characteristics based on the language of the user using that client.

NLS_LANG defines the client terminal's character encoding scheme. Different clients can use different encoding schemes. Data passed between the client and the database server is converted automatically between the two schemes. This conversion is completely transparent to the user and the client application.

Whenever the database character set and the client computer's character set are the same, Oracle simply assumes that whatever data is being sent from the client or received by the client will be the same character set; therefore, no validation or conversion is done with that data. This scenario has the distinct advantage of providing better performance. It also has the disadvantage of allowing data inconsistency in the database, which occurs when data from one character set is actually stored that is different from what the database understands is being sent from the client.

For example, if your database's character set is US7ASCII and you are using Russian or Chinese as the character set on your client computer by setting the NLS_LANG accordingly, but Oracle isn't aware of this difference, Oracle will treat every character sent as a single character and store it in a single byte in the database. All SQL string manipulation functions (for example, INSTR, SUBSTR, LENGTH, or TOCHAR) will be based on bytes (because Oracle assumes that one byte is one character) rather than on the characters. What's worse, all non-ASCII characters could either be lost or misrepresented. This is particularly true following an export/import operation where the data is taken as a stream of bits rather than any implicit interpretation taking place.

The ORA_NLS33 is an environment variable that points to a directory containing all the locale-specific data necessary for a multilingual database and is only strictly necessary if you are using a language other than English. If ORA_NLS33 is not defined, the default value of $ORACLE_HOME/ocommon/nls/admin/data or %ORACLE_HOME%\ocommon\nls\admin\data for Windows is used.

If the environment variable on the database's host computer ORA_NLS33 is set to an invalid directory, it is possible to inadvertently create a database that has only the default database character set, US7ASCII.

ORA_NLS33 should be set to $ORACLE_HOME/ocommon/nls/admin/data on Unix, or on Windows it should be set to %ORACLE_HOME%\ocommon\nls\admin\data. These are also the default settings if no explicit settings are made to the ORA_NLS33 environment variable.

Now we will look at how to control these variables with the ALTER SESSION command.

Using ALTER SESSION to Set Environment Variables

Because most of the language-dependent behavior can be altered at the session level, it is possible to alter these behaviors dynamically for any and every session that connects to the database. This is true for the environment variables and the way that they are interpreted and also for the initialization parameters.

This is accomplished through the use of the ALTER SESSION command. An example of resetting the date format parameter, NLS_DATE_FORAMT, to the value DD.MM.YYYY follows. The two commands are interchangeable:

ALTER SESSION SET NLS_DATE_FORAMT = 'DD.MM.YYYY';

DBMS_SESSION.SET_NLS('NLS_DATE_FORMAT','''DD.MM.YYYY''');

SQL*Plus reads the values to which each of these environment variables is set when it starts and invisibly issues the corresponding ALTER SESSION command so that the user doesn't need to do anything special to simply use these customized settings.

Now we will look at some of the other features that Oracle provides for the support of National Language features.

Sorting with user queries is a big deal. When you have multiple languages in the query, these sorts become more complex.


Linguistic Sorting

For the convenience of those using National Language Support, Oracle provides three different types of sorting: binary, monolingual, and multilingual. This section describes these different types of sorts. Different languages have different sort characteristics that are entirely unique to that language. Ñ will sort differently than N if sorted based on the Spanish language alphabet and if then sorted based on binary values of the represented characters. Providing the information to the user in the correctly sorted order will be important so that the results are in the order that they are expected.

Binary Sorting

Binary sorting, the conventional sorting mechanism, uses Oracle's default characteristics and sorts the values based on the binary values of the encoded characters (the letters). The alphabetic position of a character may differ somewhat from one language to another. This is the default sorting characteristic of the database unless something else is specified.

Monolingual Sorting

Monolingual sorting sorts the data in two passes. This sort algorithm is based on a character's assigned values (both the major value and the minor value). The first pass through the string is used to compute the major value for the entire string, and the second pass is used to compare the minor value for the entire string. Typically, letters with the same appearance will have the same major value but may have different minor values. Monolingual sorting provides better sorting than binary but still has its limitations. Oracle currently supports 68 monolingual sorts.

Multilingual Sorting

For multilingual sorting, Oracle provides a new sorting mechanism. Multilingual sorting is based on the new ISO 14651 standard and Unicode 3.0 standard for multilingual collation. This sorting mechanism allows each language to properly sort each and every encoded character. Currently, Oracle supports 13 different multilingual sorts.

NLS_SORT

The NLS_SORT environment variable specifies the type of sort to be used for character data. It is defined as a subtype of the NLS_LANG environment variable, so if the NLS_SORT is not applicable for the language set in the NLS_LANG variable, the NLS_LANG setting will take precedence. The settings for NLS_SORT can be altered at the session level.

NLSSORT

The NLSSORT function specifies the type of sort that should be performed for character data and allows sorts to be defined specifically at the query level. This allows for more fine-grained control of sorting behavior because the session's default can be allowed to be set at one setting, and each query can be run with a different setting if necessary.

The following section discusses language-dependent application behavior.


Language-Dependent Application Behavior

SQL functions support both single-byte and multibyte characters. Some SQL functions require that appropriate NLS parameters be specified explicitly as a part of their parameter list for the functions to perform properly. In this way, not only can the environment variables override the default behavior at the database level, but you can also allow the SQL functions to override the environment variables' default behavior without having to alter the session. This behavior can be seen in the following SQL statement:

[View full width]

Select To_char(birthday_date, 'DD.Mon.YYYY', 'NLS_DATE_LANGUATE=FRENCH') as "Birth Date"
   from employee_info;

Table 7.2 shows the SQL functions that use NLS parameters and the parameters that they are willing to accept.

Table 7.2. SQL Functions and NLS Parameters

SQL Function

NLS Parameter

TO_DATE

NLS_DATE_LANGUGE

NLS_CALENDAR

TO_NUMBER

NLS_NUMERIC_CHARACTER

NLS_CURRENCY

NLS_ISO_CURRENCY

TO_CHAR

NLS_DATE_LANGUAGE

NLS_NUMERIC_CHARACTER

NLS_CURRENCY

NLS_ISO_CURRENCY

NLS_CALENDAR

NLS_UPPER

NLS_SORT

NLS_LOWER

NLS_SORT

NLS_INITCAP

NLS_SORT

NLSSORT

NLS_SORT

Several format mask elements have been defined for the SQL functions (such as TO_CHAR, TO_DATE, and TO_NUMBER) to facilitate the use of National Language Support. These format elements follow:

  • Number format mask elements:

    • D is used for decimal separator.

    • G is used for the group (hundreds, thousands, millions…) separator.

    • L is used for local currency symbol.

    • C is used for local ISO currency symbol.

    • U is used for the dual currency symbolused for the euro.

  • Date format mask elements:

    • RM, rm are allowed for Roman month number.

    • IW is for ISO week number.

    • IYYY, IYY, IY, and I are for ISO year.

Not only is there support for language-dependent applications there also is support for language-dependent indexing.

Linguistic Index Support

Oracle provides further support for national languages by allowing linguistic indexing. You can realize high performance gains with local sorting based on linguistic indexes. Functional indexes (described further in Chapter 13, "Managing Indexes," and in Chapter 12, "Managing Tables") can be highly specialized to create linguistically sorted indexes. The SQL function NLSSORT returns the string of bytes used to sort the first parameter in the given sorting sequence.

The NLS_COMP parameter is included by Oracle for linguistic comparisons. NLS_COMP is another dynamic initialization parameter that controls how the comparison operators (<, >, between, and =) handle linguistic ordering. If the sort method is BINARY, the default, comparison is based entirely on the binary value of the different strings. When the sort method is ANSI, the comparison operators use the linguistic sorting sequences to determine the ultimate outcome of the comparison operations according to the NLS_SORT parameter that takes precedence at the time at the session level.

There are also linguistic extensions that allow for national language-based loading and importing of data into the database.

Importing and Loading Data Using NLS

If you export data from any given database, that export file will contain data with the source database's character set. When importing data using IMPORT and NLS, the data will be converted from the export file's character set to the database character set of the target database during the import operation.

SQL Loader has also been built with the capability to convert the data from one database character set to the other.

SQL*Loader, using conventional load, will convert the data into the session character set specified by the NLS_LANG environment variable. Using direct load with SQL*Loader, the data is converted directly into the character set of the database. In SQL*Loader conventional loads, input records are parsed according to their field specifications just as they would be in a standard INSERT statement, and each data field is copied to its corresponding bind array. When either the bind array is full or when there is no more data left to read, the array is inserted into the table. On the other hand, direct loads parse the input records according to the field specifications, convert the input field data to the column data types, and build a column array in the same format as the table into which you are putting the data. The column array is passed to a block formatter, which creates data blocks in the specific database block format of the database in question. These blocks are written directly to the database, bypassing most RDBMS processing, typically making them much faster than conventional path load.

The SQL*Loader control file provides SQL*Loader with the information necessary to determine what character set is to be used with each data file.

The following is a SQL*Loader command-line command containing the character set that needs to be used for the given load. In the case of this command, the control file will be loading, apparently, the Spanish employee table and will use the WE8ISO9959P1 character set for the load.

$sqlldr control=Spanish_employee.ctl characterset=WE8ISO9959P1

You will likely need, at some point, to determine information on the National Language Support features in the database. As with everything else connected to the database and the instance, you can find information in the data dictionary.


Globalization Support Information in the Data Dictionary

You can obtain information about the settings for NLS database parameters and character sets from the data dictionary using V$NLS_ parameter views. These views are available regardless of the NLS settings of your database; however, they are only truly relevant and useful under the multilingual conditions.

V$NLS_PARAMETERS

To view the database and national character set information, you could easily run the following query:

SELECT parameter, value
FROM nls_database_parameters
WHERE parameter like '%CHARACTERS%';

You would have returned the NLS_CHARACTERSET and the NLS_NCHAR_CHARACTERSET and the values for each of those parameters.

V$NLS_PARAMETERS provides the current values that are set for each of the National Language Support parameters in the database.

V$NLS_VALID_VALUES

V$NLS_VALID_VALUES provides all the valid values that each NLS parameter can take.

But where would a DBA be without access to utilities, the backbone of your daily life? Globalization provides an extended set of utilities that we will cover next.


Globalization Support Utilities

Oracle provides you, as the DBA in the increasingly global community, with a set of utilities that will assist you with your job in the globalized environment.

Oracle Locale Builder

Oracle Locale Builder provides an easy-to-use GUI that you can use to facilitate viewing, modifying, and creating locale definitions.

Oracle 9i provides an extensive set of locale definitions that include the languages, territories, character sets, and linguistic sorts that go along with those locales. If you have need to customize any of these existing definitions, or you need to create a new one, the Oracle Locale Builder will assist you in this with an easy-to-use interface through which you can easily view, customize, and define various locale information.

Character Set Scanner

The character set scanner allows you to scan the database to determine whether the character set can be safely changed. It reports on possible problems and fixes that are necessary to undertake the character set migration.

The character set scanner is a command-line utility whose sole purpose is to assist you with character set conversion. It helps to identify areas of possible data loss due to truncation associated with incompatibilities in the character sets. It also identifies the amount of effort required to perform the conversion, and the columns that should be expanded and to what they should be expanded to safely store the new data. The character set scanner provides an overall assessment of the feasibility of the conversion, reports potential migration issues, and checks all the character data to generate its overall summary.

Prior to any character set conversion, the character set scanner should be used, even if you don't think that there are any incompatibilities.


Exam Prep Questions

1:

Where would you look for your database's national character set?

  • A. V$NLS_PARAMETERS

  • B. V$NLS_VALID_VALUES

  • C. V$PARAMETERS

  • D. V$VALID_VALUES

A1:

Answer A is correct; V$NLS_PARAMETERS will give you your national character set. Answer B is incorrect; V$NLS_VALID_VALUES will give you all the valid values that you can have for your national character set but not the current value. Answer C is incorrect; V$PARAMETERS will not provide you with information on your NLS parameters. Answer D is incorrect because V$VALID_VALUES is not an Oracle 9i data dictionary view.

2:

Where would you look for the list of all valid values for the database's NLS parameters?

  • A. V$NLS_PARAMETERS

  • B. V$NLS_VALID_VALUES

  • C. V$PARAMETERS

  • D. V$VALID_VALUES

A2:

Answer B is correct; V$NLS_VALID_VALUES provides all the valid values for a given parameter. Answer A is incorrect; V$NLS_PARAMETERS gives you your NLS parameters and their current values. Answer C is incorrect; V$PRAMETERS does not provide information on your NLS parameters. Answer D is incorrect because V$VALID_VALUES is not an Oracle 9i data dictionary view.

3:

What parameter would you alter to be able to override the default currency of the English pound by the euro at the same time?

  • A. NLS_ISO_CURRENCY

  • B. NLS_CURRENCY

  • C. NLS_DUAL_CURRENCY

  • D. NLS_MONETARY_CHARACTERS

A3:

Answer C is correct; you can use NLS_DUAL_CURRENCY to override the default currency for the given territory. Answer A is incorrect; NLS_ISO_CURRENCY is the ISO currency symbol for the territory. Answer B is incorrect; NLS_CURRENCY is the default local currency symbol for a particular territory. Answer D is incorrect; NLS_MONETARY_CHARACTERS specifies the group separator for monetary expressions for the territory.

4:

Which sort method provides more sorting flexibility with respect to multiple languages?

  • A. Binary sorting

  • B. Multilingual sorting

  • C. Monolingual sorting

  • D. Linguistic sorting

A4:

Answer B is correct; multilingual sorting is the most efficient for sorts involving multiple languages. Answer A is incorrect; binary, the default sort mechanism, is the least efficient for sorts including multiple languages. Answer C is incorrect; monolingual sorting sorts in two passes and is less efficient for multiple languages than the multilingual sort method. Answer D is incorrect; linguistic sorting isn't a sort method.

5:

What two new Unicode character encoding sets did Oracle introduce in 9i?

  • A. UTF8 and UTF16

  • B. AL16UTF16 and AL32UTF8

  • C. AL16UTF16 and AL8UTF8

  • D. AL16UTF16 and AL32UTF32

A5:

Answer B is correct; AL16UTF16 and AL32UTF8 are Oracle 9i's new character set encoding schemes. Answer A is incorrect because these were encoding schemes in Oracle 8i. Answers C and D are incorrect because they are not valid encoding sets.

6:

Which is not a reason to use Unicode character encoding schemes in your database?

  • A. To make it easier to write application code

  • B. To achieve better data distribution

  • C. To see performance gains

  • D. To be able to use multilingual sorts

A6:

Answer D is correct; multilingual sorts are not directly connected to using a Unicode character set. Answers A, B, and C are incorrect because they are all reasons to use a Unicode character scheme.

7:

Which is an advantage to using fixed-width character sets in your database?

  • A. Performance gains

  • B. Easier application coding

  • C. Use of multilingual sorts

  • D. To be able to store characters in exactly the number of bytes they take up

A7:

Answer A is correct; there are performance gains to be seen with either single-byte character sets or fixed-width multibyte character sets because Oracle knows ahead of time exactly how many bytes each character will take up. Answer B is incorrect; there is no real difference in coding applications based on how many bytes a character takes up. Answer C is incorrect; there are no connections between sorts and the number of bytes that characters take up. Answer D is incorrect; it is a reason that you might consider variable-width character sets.

8:

Which is an advantage of using variable-width character sets in your database?

  • A. Performance gains

  • B. Easier application coding

  • C. Use of multilingual sorts

  • D. To be able to store characters in exactly the number of bytes they take up

A8:

Answer D is correct. If space is an issue, you might find benefit in storing data in variable-width character sets. Answer A is incorrect; variable-width character sets cause somewhat of a performance hit to the database because Oracle is unsure how many bytes each and every character will consume. Answer B is incorrect; there is no real difference in coding applications based on how many bytes a character takes up. Answer C is incorrect; there are no connections between sorts and the number of bytes that characters take up.

9:

Which is a valid Oracle 9i pair of Unicode character encoding sets?

  • A. AL16UTF16 and AL8UTF8

  • B. AL16UTF16 and AL32UTF8

  • C. AL32UTF16 and AL8UTF8

  • D. AL8UTF16 and AL16UTF8

A9:

Answer B is correct; the only answer that provides a correct pair of Unicode character encoding sets is B.

10:

In Windows, how can you temporarily override the default value set for the NLS_LANG environment variable?

  • A. With the ALTER SYSTEM command

  • B. With the ALTER SESSION command

  • C. Manually edit the Registry

  • D. At the command prompt

A10:

Answer D is correct; you can override the value for NLS_LANG on Windows at the command prompt. Answers A and B are incorrect; you can't simply set the values in SQL*PLUS. Answer C is incorrect; you shouldn't edit the Registry to temporarily change a parameter value.


Chapter 8. Maintaining Control Files

Terms you'll need to understand:

  • MAXLOGFILES

  • MAXLOGMEMBERS

  • MAXLOGHISTORY

  • MAXDATAFILES

  • MAXINSTANCES

  • GLOBAL_NAME

  • DBA_DATA_FILES

  • V$CONTROLFILE

  • V$DATABASE

  • V$DATAFILE

  • V$LOG

  • V$LOGFILE

Concepts you'll need to master:

  • Explain the uses of the control file

  • List the contents of the control file

  • Multiplex the control file

  • Manage the control file

  • Obtain control file information

  • Manage the control file with Oracle Managed Files


What Are Control Files?

The control file is a binary file that defines the current state of the physical database. The control file is one of the core files at the heart of the Oracle database. Together, this means that the Oracle instance itself is the only means by which the contents of the control file should ever be modified. The DBA should only modify it indirectly by means of altering the database. Loss or corruption of the control file requires a database recovery.

The control file is read at the mount stage of database startup and is required for the database to be functional. Each control file is linked to a single database. Before the database is opened, Oracle reads the control file to determine whether the database is in a valid state to use. The control file is updated almost continuously by the Oracle server when the database is in use and therefore must be available for write processing whenever the database is open.

The control file should be multiplexed (multiple identical copies located in multiple locations, preferably on different disks, hard drives, or other devices) or at least duplexed (two identical copies located in two different locations, preferably on different disks, hard drives, or other devices), because it maintains the integrity of the database, and loss of a single control file could mean significant downtime and loss of productivity in the database. If for any reason the control file is not accessible when the database is open, the database will not function properly. If all the copies of the database's control files are lost, the database must be recovered before it can be opened.

Although the control file doesn't have to be multiplexed, and it is suggested that it be at least duplexed, it is possible that they be multiplexed up to a maximum of eight times.

The initial size of the control file is determined when the database is first created. The keywords, during database creation, that affect the initial size of the control file are the following:

  • MAXLOGFILES

  • MAXLOGMEMBERS

  • MAXLOGHISTORY

  • MAXDATAFILES

  • MAXINSTANCES

Uses of the Control Files

Every time you start up an instance of Oracle, the control file is read and used to identify the database and redo log files that need to be opened for database operation to successfully proceed.

Every time the physical characteristics of the database are altered (every time a new data file is added to a tablespace, a new tablespace is added to the database, or a new redo log file is created), Oracle writes this information to the control file so it can retrieve that information later, when it is needed.

Oracle also uses the control file to support the Recovery Manager (RMAN) feature. RMAN stores metadata about its operations in the control file for the database that it is operating on, if you choose to not use the recovery catalog schema for this purpose.

More information on RMAN and its options will be needed when you prepare for the Oracle 9i Fundamentals 2 exam and is covered in Oracle DBA Fundamentals II test preparation.

Information on preparing for this exam can be found in the OCP Oracle9i Database: Fundamentals II Exam Guide, Rama Velpuri, Osborne, ISBN: 0072195436.

Contents of the Control Files

The control file contains the database name and identifier for the database to which it is associated. This database name is taken either from the name specified by the initialization parameter DB_NAME or the name used in the CREATE DATABASE statement. The database identifier is recorded in the control file when the database is created.

The RESETLOGS SCN and associated time stamp are also found in the control file. The SCN is the system change number and is stored in every data file and in the control files and log files. Together with the RESETLOGS time stamp, the RESETLOGS SCN is the unique identifier for the execution time of the last ALTER DATABASE OPEN RESETLOGS statement. Whenever you enter the RESETLOGS parameter for the ALTER DATABASE OPEN statement, Oracle creates a new incarnation of the database.

An incarnation is a separate version of the physical database. This means that you now would have to restore from a cold backup because you can't easily restore the database to the state that it was in immediately before the RESETLOGS command. You should make a whole database backup after you issue the RESETLOGS command.

The RESETLOGS SCN and RESETLOGS time stamps are stored in the control file and in the header of each data file in the database, and in each redo log file header in the database. An online log or an archived redo log cannot be applied in a recovery if its RESETLOGS data does not exactly match the database and RESETLOGS information in the control file.

There are only a few special circumstances where a data file can be recovered if its RESETLOGS information does not match that of the control file. These include offline normal tablespaces or read-only tablespaces.

The control file contains the time stamp of database creation (recorded at the time when the CREATE DATABASE script is run), tablespace names for every tablespace in the database, and the names and locations of all data files and redo log files. These names and locations are updated whenever a data file or redo log file is added to, renamed in, or dropped from the associated database. Tablespace information is updated whenever a tablespace is either added to the database or dropped from the database.

The control file contains the current redo log file sequence number, redo log archiving information, and checkpoint information. Redo log history is recorded during log switch operations. Locations and statuses of archived redo logs are recorded whenever archiving occurs in the instance. Current log sequence numbers are recorded in the control file when log switches occur, and checkpoint information is recorded as checkpoints are made in the database.

Furthermore, the control file contains the beginning and ending of undo segments and relevant backup information. Locations and statuses of backups are recorded by the RMAN utility if an RMAN recovery catalog is not used.

The control file consists of two types of sections: reusable and not reusable.

Reusable Sections

Reusable sections of the control file store recovery manager information, such as backup data filenames and backup redo log filenames. These names are circular in nature, meaning that they can be reused and recycled when necessary, but only by the RMAN utility.

More on the RMAN utility is provided in Oracle DBA Fundamentals II test preparation.

Information on preparing for this exam can be found in the OCP Oracle9i Database: Fundamentals II Exam Guide, Rama Velpuri, Osborne, ISBN: 0072195436.

Nonreusable Sections

The nonreusable portion of the control file is where information about data file, tablespace, and redo thread records (for example) are stored, along with any other information that never gets reused. These nonreusable entries are, of course, nonreusable unless the corresponding object is dropped from the database.

A control file contains all the information about its associated database that is or will be required for access of that database by an instance, both at startup time and during normal operations. It is information that has to be altered indirectly by Oracle; no database administrator or user can edit a control file.


Multiplexing Control Files

To protect the database from a single point of failure occurring in the control file, it is strongly recommended by Oracle that the control file be multiplexed and each copy stored to a different writable disk. If the primary control file is for any reason lost, the database can continue using the multiplexed version, and the instance and database can be restarted (after alteration of the primary control file to one of the backup locations and restarting the instance and database) without the necessity of database recovery. Control files can be multiplexed up to a maximum of eight times. The Oracle server is responsible for creating and maintaining all files listed in the CONTROL_FILES parameter when the instance is started.

Multiple control files can be created when you create the database by setting the CONTROL_FILES initialization parameter to the comma-delimited list of control file location and names.

CONTROL_FILES='/mydatabases/mydb1/control01.ctl', '/mydatabases2/mydb1/control02.ctl'

After the database has been created, you can add additional control files. The steps to defining the additional control files differ depending on whether you are using the PFILE or the SPFILE to initialize the database instance.

Multiplexing Using SPFILE

If you are using the server parameter file (SPFILE) to start the instance, follow these steps:

1.
First alter the SPFILE using SQL:

ALTER SYSTEM SET CONTROL FILES =
 'd:\mydatabase\mydb1\control01.ctl',
'e:\mydatabase\mydb1\control02.ctl' SCOPE=SPFILE;

2.
Shut down the database either in normal mode, or immediate mode:

shutdown immediate

3.
Create the new control files using your operating system's copy command.

4.
Restart the database:

startup mydb1

You now have multiplexed the control files.

Multiplexing Using PFILE

If you are using the PFILE (init SID.ora), do the following:

1.
Add the new control filename to the init SID.ora file:

CONTROL_FILES = ('/mydatabases/mydb1/control01.ctl', '/mydatabases2/mydb1/control02.ctl')

2.
Shut down the database in either normal or immediate manner:

shutdown immediate

3.
Copy the existing control file to the new name and location using your operating system's copy command.

4.
Start up and open the database, and you have multiplexed your database.

The following describes the behavior of multiplexed control files:

  • Oracle writes to all the files designated in the list for the initialization parameter CONTROL_FILES in the database's initialization parameter file.

  • The first file listed in the CONTROL_FILES parameter is the only file read by the Oracle database server during database operation.

  • If, however, any of the control files become unavailable during database operation, the instance becomes inoperable and should be closed, often resulting in the necessity of shutdown abort. It can, however, be reopened with one of the multiplexed or the other duplexed version of the control file with the alteration of the PFILE to point to the backup's location. If you have only one control file, you would need to recover the database to reopen it for operation.


The CREATE CONTROLFILE Command

It is possible to create a control file, not only at database creation time but also after the database is created and running. It can be created indirectly by using the BACKUP CONTROLFILE TO TRACE command or by the BACKUP CONTROLFILE command, or it can be created directly by the CREATE CONTROLFILE command.

The CREATE CONTROLFILE command allows you to create a control file from scratch. It is important that you have a complete detailed understanding of the database and its contents to use it correctly.

The CREATE CONTROLFILE command is used to re-create a control file whenever all viable copies of the existing control files have been lost because of media failure; whenever you need to change the name of the database; or whenever you need to change the maximum number of redo log file groups, the maximum number of redo log file members, the maximum number of data files, or the current number of instances that can concurrently have the given database mounted and open for operation.

Not only does Oracle recommend backing up the database before you re-create the control files, but it's a good idea to perform a full database backup of all database files before you use the CREATE CONTROLFILE command. This allows you to get back to where you are if anything in the process should fail.

The general syntax for the CREATE CONTROLFILE command follows:

CREATE CONTROLFILE [REUSE]
    [SET] DATABASE database
    LOGFILE [GROUP integer] filespec [, [GROUP integer] filespec] ...
    {RESETLOGS | NORESETLOGS}
    DATAFILE filespec [, filespec] ...
    [MAXLOGFILES integer]
    [MAXLOGMEMBERS integer]
    [MAXLOGHISTORY integer]
    [MAXINSTANCES integer]
    [ARCHIVELOG | NOARCHIVELOG]

CREATE CONTROLFILE Parameters and Options

The definition of the commands and parameters are as follows:

  • CREATE CONTROLFILE is the command that allows Oracle to create the new control file.

  • REUSE specifies to the create command that any existing control files that are identified by the initialization parameter CONTROL_FILES can be reused. This means that these files will be overwritten with the new parameters, so make sure that it is really what you want. Whenever I have to take this step, I execute a BACKUP CONTROLFILE TO TRACE command as it stands, so it is easy to get back to this point. If you omit the REUSE command, and the control files in the initialization file exist, the create command will return an error and fail.

  • SET DATABASE is an optional parameter and should only be used when you are changing the name of the database. This is useful in cloning one database to another where you want to carry the target's name with the source's data. The name of the database can be up to eight characters.

  • DATABASE is used when you are creating a control file and using the existing database's name. The value that you provide for this parameter must be the existing database name established either by the previous CREATE DATABASE command or a previously run CREATE CONTROLFILE command.

  • LOGFILE specifies the redo log file groups and log file members for your database. You must include in this list all the members of all redo log file groups, and all files specified must exist.

  • RESETLOGS command causes the CREATE CONTROLFILE to ignore the contents of the log files listed in the LOGFILE clause of the initialization file. Each file spec in the LOGFILE clause must specify the SIZE parameter for the CREATE CONTROLFILE command to be successful. After using this option in the CREATE CONTROLFILE command, you must open the database with the RESETLOGS option of the ALTER DATABASE OPEN command.

  • NORESETLOGS command causes all the files in the LOGFILE clause of the initialization file to be used as they were when the database was last open. This means that the files must be the current redo log files from right before the database was shut down (or crashed) and not ones restored from backup. Oracle reassigns the redo log file groups to the processes to which they were assigned when they were previously open. If you specify the GROUP values, Oracle also verifies these values with the actual values when the database was last open.

  • DATAFILE specifies all the data files of the database. You must specify all the data files that were in the database when it was last open. The files specified must exist in the operating system. They can be files that have been restored from backup, although if they are files that have been restored, you will have to perform media recovery on these files before the database will open. Media recovery refers to the application (or reapplication) of redo to restore a data file or individual data block to a specified time. Data file media recovery always begins at the lowest SCN recorded in the data file headers and rolls forward to the current SCN.

  • MAXLOGFILES specifies the maximum number of redo log file groups that can ever be created in the database. The Oracle server uses this value to determine how much space in the control file needs to be allocated for the names of redo log files. The default number assigned to MAXLOGFILES is operating system dependent should the parameter not be included in the CREATE CONTROLFILE command. The value that you assign to this parameter should not be a lower value than the greatest GROUP value for current redo log file groups.

    MAXLOGFILES is not the only parameter that governs the number of redo log file groups accessible to the instance. The LOG_FILES parameter in the initialization parameter file helps to govern the number as well because it limits the files created to the files listed in the parameter.

    If the maximum number of log files required for your database changes, and MAXLOGFILES is too low, either the database or, minimally, the control file will have to be re-created to reflect the requirements.

  • MAXLOGMEMBERS is the parameter that specifies the maximum number of copies, or members, of files for a redo log file group. This value is used by Oracle to help determine how much space in the control file to allocate to use for the names of the redo log files. The minimum number is 1; the maximum value for this parameter is operating system dependent.

  • MAXLOGHISTORY provides information on the maximum number of redo log file groups for automatic media recovery. Again, Oracle uses the value of this parameter to help to determine how much space to allocate inside the control file for the names of archived redo log files. The minimum number for this parameter is 0. The maximum value is limited only by the maximum size of the control file. The default value for this parameter is a multiple of the MAXINSTANCES parameter value and varies depending on your operating system.

    MAXLOGHISTORY is particularly useful if you are using Oracle with the Parallel Server option in both Parallel and Archivelog mode but can also be beneficial in assisting with recovery in a RAC environment where there are many instances and many log files.

  • MAXDATAFILES specifies the maximum number of data files that can be created in your database. The minimum value is 1 (however, this in really not a practical number). The maximum and default values for this parameter vary based on your operating system. Whatever value you specify for this parameter must not be lower than the total existing number of data files that have ever been in the database, including those connected to any tablespaces that may have been dropped.

    The number of data files accessible to your instance is limited not only by MAXDATAFILES, it is also limited by the initialization parameter DB_FILES.

    MAXDATAFILES is the maximum number of data files that can be in a control file. When that number is reached, the control file needs to be re-created. The DB_FILES initialization parameter can be used to set an artificial limit to the number of data files that can be associated with a database. In this case, after the number of files has been reached, it is necessary to change the value of the parameter and restart the database and its instance.

  • MAXINSTANCES is the maximum number of instances that can simultaneously have the given database mounted and open. This value takes precedence over even the value of the initialization parameter INSTANCES. The minimum value for this parameter is 1 because your database wouldn't be much good if you didn't have at least one instance able to open it. The maximum and default values are, again, operating system dependent.

    This parameter is really only applicable in a RAC environment.

  • ARCHIVELOG parameter signals Oracle that the database should be opened with archiving turned on, meaning that the contents of every redo log file should be archived before reusing them. ARCHIVELOG allows for the more elegant possibility of media recovery and instance recovery.

  • NOARCHIVELOG tells Oracle that it should allow for the reuse of redo log files without first archiving their contents. NOARCHIVELOG allows for the ability to do instance recovery elegantly, but media recovery becomes more difficult. If you omit both the ARCHIVELOG and NOARCHIVELOG keywords, Oracle chooses to use NOARCHIVELOG mode by default. You can change this behavior after the new control file creation by use of the ALTER DATABASE command.

Before you can run CREATE CONTROLFILE, you need to be logged in with SYSDBA privileges, and the database in question must not be mounted by any instance.

CREATE CONTROLFILE Troubleshooting

After you create your new control file and after you have used it to open the database, always check the alert file (located, remember, in the BACKGROUND_DUMP_DESTINATION) to see whether Oracle detected any inconsistencies between what the data dictionary includes but that does not appear in the control file.

If a data file happens to exist in the data dictionary but does not appear in the new control file, Oracle creates a placeholder entry in the control file with the naming convention MISSING nnnn, where nnnn is the file number in decimal format. This file, MISSING nnnn, is flagged in the control file as being offline, because the control file doesn't understand where or what it really is, and is in need of media recovery. The actual data file that corresponds to the MISSING nnnn file can be made to be accessible by renaming the MISSING nnnn so that it really points to the data file. This is only possible if the data file was read-only or offline normal at the time of startup.

If the file MISSING nnnn does not correspond to a data file that was not either read-only or offline normal, the rename operation cannot be used to make the data file accessible. This is because the data file in question requires media recovery. Because there is inconsistency between the RESETLOGS SCN and the RESETLOGS time stamp in the data file and the control file, the file needs to be recovered. This is one of the reasons that you have to be careful when you manually create the control file with the CREATE CONTROLFILE command, because now this tablespace and its file (or files) are no longer viable but have to be offline dropped and re-created.

If, on the other hand, you have created a reference in the control file that is not present in the data dictionary, Oracle removes the references to it from the control file.

In all these cases, Oracle places a message in the alert SID.log file explaining what was found, what was not found, and what it decided to do about it. These files, unless changed in the init SID.ora file, can be found in the $ORACLE_HOME/admin/SID/bdump directory under Unix or the %ORACLE_HOME%/admin/SID/bdump on Windows.

On the other hand, Oracle will often be gentle enough to send you an error when you attempt to mount the database and open it after creating the new control file (typically an ORA-01173, ORA-01176, ORA-01177, ORA-01215, or ORA-01216). This most often happens because you have omitted a file from the CREATE CONTROLFILE command or have included one that shouldn't be included. If you get one of these errors, you can just go back and alter the DATAFILES section of the CREATE CONTROLFILE command, either adding a missing one or removing an errant one, and then rerun the script.

If you want to be sure that you always get exactly the files and tablespaces found in the data dictionary, you should query the data dictionary to determine what it believes needs to be in the control file. You can get the tablespace name, filename, and sizing information from the DBA_DATA_FILES view that will help you to make sure that you have included exactly what is in the data dictionary when creating the control file.

Because the DBA_DATA_FILES is not one of the dynamic (or V$) views, the information in this view is not available to you unless the database is mounted and open. It is important that you retrieve the information needed from this view before you need to re-create the control file because the database will be inaccessible when the previous control file is gone.


Dropping Control Files

Not only can you create new control files, you can also drop control files from the database. Say, for example, that you want to change the location of a control file because you determine that the current location is inappropriate. Before you decide that you are going to drop a control file, however, remember that the database must have at least two control files at the time when the drop occurs, and you should immediately multiplex them after you have deleted one.

To drop a control file, proceed with the following steps:

1. | Shut down the database.
2. | Edit the CONTROL_FILES parameter in the database's parameter file to delete the old control file's name.
3. | Restart the database.

This operation does not physically delete the unwanted control file from the disk. This means that there is a chance later that you will errantly try to use this control file to start your database. Use operating system commands to delete the unnecessary file after (and only after) you have dropped the control file from and successfully restarted the database.


Backing Up the Control File

Because control files record the physical structure of the database, always make a backup of the control file immediately after making any changes to the physical structure of the database. You can create a backup of the control files at any time the database is operational; however, you cannot restore a control file from a backup without the full contingent of the associated data files. This is because the control file is a living and growing file that corresponds exactly to the database's status at that particular point in time.

As long as you have the data files stated in the control file, you can restore the control file safely.

There are two different ways to create a backup of the control file. You can either back up the control file to a specific filename, or you can back it up to trace.

The following command allows you to back up the control file to the given file's name:

ALTER DATBASE BACKUP CONTROLFILE TO 'filename'

You can also back up the control file to a trace file as follows:

ALTER DATABASE BACKUP CONTROL FILE TO TRACE

This creates a file with the .trc extension in the user dump destination directory that contains the SQL required to re-create your control file.

Further information on backing up and recovery of the control files is explored in detail in preparation for the Oracle 9i DBA Fundamentals II test.


Obtaining Control File Information

If the control file is something that is important to be able to manage, it is something that you need to be able to find information on. How do you find information about the control files from the database? Table 8.1 provides the data dictionary views that provide information about the control files connected to your database and your instances.

Table 8.1. Data Dictionary Views for Control Files

Data Dictionary View

Description

V$DATABASE

Displays database information from the control file including the following:

CONTROLFILE_TYPE

CONTROLFILE_CREATED

CONTROLFILE_SEQUENCE#

CONTROLFILE_CHANGE#

CONTROLFILE_TIME

V$CONTROLFILE

Lists the names and status of all control files

V$CONTROLFILE_RECORD_SECTION

Displays information about the control file's record sections, how much information is stored in each section of the control file. Information that can be gained from this view includes the following:

TYPE: Identifies the type of record section to which the record pertains. Values include DATABASE, CKPT PROGRESS, REDO THREAD, REDO LOG, DATAFILE, FILENAME, TABLESPACE, LOG HISTORY, OFFLINE RANGE, ARCHIVED LOG, BACKUP SET, BACKUP PIECE, BACKUP DATAFILE, BACKUP REDOLOG, DATAFILE COPY, BACKUP CORRUPTION, COPY CORRUPTION, DELETED OBJECT, or PROXY COPY.

RECORD_SIZE: In bytes

RECORDS_TOTAL: Number of records in the given section

RECORDS_USED: Number of records used in the given section

FIRST_INDEX: Position (INDEX) of the first record

LAST_INDEX: Position (INDEX) of the last record

LAST_RECID: Record ID of the last record in the section

V$PARAMETER

Can be used to display the names of control files as specified in the CONTROL_FILES initialization parameter

The following example lists the names of the control files:

SELECT NAME FROM V$CONTROLFILE;

This produces the following output:

NAME
-------------------------------------
/mydatabases/mydb1/control01.ctl
/mydatabases2/mydb1/control02.ctl


Control File-Related Parameters

CONTROL_FILE_RECORD_KEEP_TIME, a dynamic parameter, takes an integer value as its argument. The value of this parameter is the number of days that minimally must pass before any portion of the reuse section of the control file can be overwritten and reused. If the CONTROL_FILE_RECORD_KEEP_TIME amount of time has not passed for the oldest record in the reusable section and an additional record needs to be added, the record section (and by extension the control file) expands to allow for the insertion. The allowable values are any whole number between 0 and 365. If the CONTROL_FILE_RECORD_KEEP_TIME is set to 0, the control file never expands, and records are overwritten as needed.

It is important to remember that this parameter applies on the records in the control file that are circularly reusable (archive log records and backup records primarily). It does not apply to records concerning data files, tablespaces, redo thread records, and the like. These records are never reused unless the corresponding objects are dropped from the database.


Managing the Control File with OMF

Control files, when using Oracle Managed Files (OMF), are created in the default location (DB_CRFEATE_ONOINE_LOG_DEST_n) if they are not specified in the CONTROL_FILES initialization parameter.

Control files names are uniquely generated, and the creation information, along with the filename, is displayed in the alert SID.log file in the background dump destination location when the files are created.

If you are using a parameter file, the init SID.ora, as well as OMF, you must set the CONTROL_FILE parameter to the OMF-generated names after they have been created. You can find the filenames in V$CONTROLFILE or from the alert SID.log where the creation shows up.

If you are using SPFILE with OMF, the CONTROL_FILES parameter is automatically set and saved into the file. You can create the database with the OMF parameters set and, as soon as the database is created, create the SPFILE from the PFILE. The unique control filenames will be placed there and saved.

If you create a new control file using the CREATE CONTROLFILE command, the correct names must be used for the OMF DATAFILE and LOGFILE clauses. If you use ALTER DATABASE BACKUP CONTROLFILE TO TRACE, it generates a script as discussed previously with the correct OMF-created filenames.


Exam Prep Questions

1:

Your database currently has one control file. You, after careful consideration, decide that adding two more control files will provide better protection against a single point of failure at the control file level. To accomplish this, you edit the init SID.ora file to point to the new location.

control_files='/mydatabases/mydb1/control_01.ctl',
'/mydatabases02/mydb1/control_02.ctl',
'/mydatabases03/mydb1/control_03.ctl'

You shut down your database normal and copy the control files to the new location.

Cp /mydatabases/mydb1/control_01.ctl /mydatabases2/mydb1/control_02.ctl
Cp /mydatabases/mydb1/control_01.ctl /mydatabases3/mydb1/control_03.ctl

When you restart your database using the altered PFILE, you receive the error

ORA-00205: error in identifying control file

You look in the alert log, and determine that you specified the incorrect path for the control files. Which steps are required to resolve the problem and restart the database?

  • A.

    1. Connect Internal.

    2. Shut down the database.

    3. Start up the database in NOMOUNT mode.

    4. Use the ALTER SYSTEM SET CONTROL_FILES command to correct the error.

    5. Shut down the database.

    6. Start up the database.

  • B.

    1. Connect as SYSDBA.

    2. Shut down the database.

    3. Start up the database in NOMOUNT mode.

    4. Use the ALTER SYSTEM SET CONTROL_FILES command to correct the error.

    5. Shut down the database.

    6. Start up the database.

  • C.

    1. Connect as SYSDBA.

    2. Shut down the database.

    3. Start up the database in MOUNT mode.

    4. Use the ALTER SYSTEM SET CONTROL_FILES command to correct the error.

    5. Shut down the database.

    6. Start up the database.

  • D.

    1. Connect as SYSDBA.

    2. Shut down the database.

    3. Fix the errant entries in the init SID.ora file.

    4. Start up the database.

A1:

Answer D is correct. The questions states that you are using init SID.ora, meaning that you are using the PFILE. It does not indicate that there is an SPFILE for the database. Therefore, you need to fix the init SID.ora and restart the database. Answer A is incorrect because Connect Internal is not a valid way of connecting to an Oracle 9i database. Answer B is incorrect because you have not been told that you have an SPFILE connected to the database. Answer C in incorrect because you will not be able to MOUNT the database without valid paths to the control files.

2:

You have decided that you want to use Oracle Managed Files for all the files in your database. Which parameter must you supply to allow Oracle to create and name the control files automatically?

  • A. DB_CREATE_FILE_DEST

  • B. DB_CREATE_ONLINE_LOG_DEST_n

  • C. DB_CREATE_CONTROL_FILE_DEST

  • D. MAXHISTORY

A2:

Answer B is correct. The parameter that needs to be specified for Oracle to automatically create and name the control files in an OMF database is DB_CREATE_ONLINE_LOG_DEST_n. Answer A is incorrect because the DB_CREATE_FILE_DEST parameter specifies the location of the data files in the database for an OMF database. Answer C is incorrect because it is not a valid parameter. Answer D is incorrect because MAXHISTORY has nothing to do directly with an OMF database.

3:

Which of the following statements provides information about the number, names, status, and location of the control files in your database?

  • A. SELECT NAME, STATUS, LOCATION FROM V$PARAMETER;

  • B. SELECT NAME, STATUS, LOCATION FROM V$CONTROLFILE;

  • C. SELECT NAME, STATUS, LOCATION FROM V$CONTROL_FILES;

  • D. SELECT NAME, STATUS, LOCATION FROM DICTIONARY;

A3:

Answers B is correct. V$CONTROLFILE provides you with the status and name of the control file. You will have to count the number of rows returned to realize how many control files you have (although the query could be altered to provide this information), and the name includes the complete path to the control files, giving you their location. Answer A is incorrect because V$PARAMETER gives you only the name of the control file. Answer C is incorrect because V$CONTROL_FILES is not a valid data dictionary view. Answer D is incorrect because the DICTIONARY view only provides information on tables and their comments.

4:

Which of the following statements are true about control files? [select all that apply]

  • A. Control files can be multiplexed up to eight times.

  • B. Control files are read at the MOUNT stage of startup.

  • C. Control files are read at the NOMOUNT stage of startup.

  • D. Control files are text files that should be edited in a text editor to define the desired state of the physical database.

  • E. Control files maintain the integrity of the database.

  • F. Loss of all the control file requires that the database be recovered.

  • G. The control file cannot be re-created after database creation.

A4:

Answers A, B, E, and F are correct. You can multiplex the control files up to eight times (and should multiplex them at least twice). The control files are read during the MOUNT stage of database startup. They are files tasked with maintaining the integrity of the database and, therefore, the loss of the only available (or all available) control file requires that the database be recovered. Answer C is incorrect; the control file is not read until the MOUNT phase of the startup. Answer D is incorrect. You should never attempt to alter the control file with a text editor; only Oracle should alter the contents of the control file. Answer G is incorrect; you can create the control file either from the file resulting from the ALTER DATABASE BACKUP CONTROL FILE TO TRACE command or through the CREATE CONTROLFILE command.

5:

You have added several tablespaces to your database. Which of the following are valid ways to back up your control file to reflect these new changes? [select all that apply]

  • A. ALTER DATABASE BACKUP CONTROLFILE TO TRACE

  • B. ALTER DATABASE BACKUP CONTROLFILE

  • C. CREATE CONTROLFILE <controlfile name>

  • D. DELETE CONTROLFILE <controlfile name>

  • E. ALTER SYSTEM BACKUP CONTROL FILE to MYBACKUP_CONTROLFILE_01.ctl

  • F. ALTER SYSTEM BACKUP CONTROLFILE TO TRACE

A5:

Answer A is correct. ALTER DATABASE BACKUP CONTROLFILE TO TRACE is the only valid included command to back up the control file. Answer B is incorrect because it is syntactically incorrect, and it will expect you to tell it where to back it up to and what filename to use as the backup's name. Answer C will create a control file if you provide the correct parameters, but will not back up the current control file. Answer D will delete a control file, not back up the control file. Answer E is incorrect because BACKUP CONTROL FILE needs to be accompanied by the ALTER DATABASE command, not the ALTER SYSTEM command. Answer F is incorrect because the BACKUP CONTROLFILE TO TRACE needs to be accompanied by the ALTER DATABASE command, not the ALTER SYSTEM command.

6:

After which of the following statements should you perform a backup of the control file? [select all that apply]

  • A. CREATE USER

  • B. CREATE DATABASE

  • C. CREATE INDEX

  • D. CREATE TABLE

  • E. CREATE TABLESPACE

  • F. ALTER TABLESPACE <tablespace name> ADD DATAFFILE

  • G. ALTER TABLESPACE <tablespace name> READ ONLY;

A6:

Answers B, E, F, and G are the correct answers. You should back up the control file after creating the database, creating a tablespace, adding a data file to an existing database, and making a tablespace read-only or read-write. Answer A is incorrect; nothing stored in the control file concerns the creation of users. Answer C is incorrect; nothing stored in the control file concerns creation of indexes. Answer D is incorrect; nothing stored in the control file concerns creation of tables.

7:

You are creating a new control file to replace ones that have been deleted. Which of the following commands is the appropriate way to start the database?

  • A. STARTUP NOMOUNT

  • B. STARTUP READ-ONLY

  • C. STARTUP OPEN

  • D. STARTUP

A7:

Answer A is correct. STARTUP NOMOUNT allows you to create a new control file without worrying about it attempting to access or open data files. Answer B is incorrect because the data files and control files have to be accessible and open for the queries in a read-only database to be processed. Answer C is incorrect because the control file has to be available to open the database. Answer D is simply a restatement of answer C and is therefore incorrect for the same reasons.

8:

You have not multiplexed your control file. You are having intermittent problems with the drive on which the control file is located, so you decide to multiplex your control file onto multiple disk drives to head off catastrophe. You have taken the following steps:

1. | Make a copy of your control file using your operating system command.
2. | Add the new filename to the list of control files parameters in your PFILE.
3. | Shut down the instance.
4. | Start up the command to restart the instance.

Why does the mount of the database fail?

  • A. You used the OS command to copy the control file.

  • B. You copied the control file with the database up and operating.

  • C. You should have started the database with the force option.

  • D. You added the new control filename to the CONTROL_FILES parameter to the init SID.ora file before you shut down the database.

A8:

Answer B is correct. The control file should not be copied until the database is shut down either immediate, normal, or transactional, when the database is consistent. Answer A is incorrect; you should use the OS copy command to copy the control file after the database is shut down. Answer C is incorrect because this only causes the instance to read the inconsistent control file in one step instead of two. Answer D is incorrect because the init.ora file is read from only when the database is started, so it doesn't matter when the text file is edited.

9:

Keeping multiple active copies of a control file for redundancy purposes is called_________.

  • A. Overkill

  • B. Multiplexing

  • C. Control file groups

  • D. Redo log groups

A9:

Answer B is correct; this is known as multiplexing. Answer A is incorrect; not only is it not known as overkill, it is wise management. Answer C is incorrect; there is no such thing as control file groups. Answer D is incorrect; these are control files, not redo log files.

10:

Which of the following are ways that Oracle identifies how Oracle knows where the control files are supposed to be maintained?

  • A. By the CONTROL_FILES parameter

  • B. By the BACKGROUND_DUMP_DEST parameter

  • C. In the V$DATABASE view

  • D. Oracle just knows where they are

A10:

Answer A is correct; the CONTROL_FILES parameter controls where the control files are placed. Answer B is incorrect; BACKGROUND_DUMP_DEST is where the alert logs and the background trace files are placed. Answer C is incorrect; the V$DATABASE view provides much information about control files but not their location. Answer D is incorrect; you have to tell Oracle where things are before it knows.


Chapter 9. Maintaining Redo Log Files

Terms you'll need to understand:

  • Online redo log files

  • Redo log groups

  • Redo log members

  • ARCHIVELOG

  • NOARCHIVELOG

Concepts you'll need to master:

  • Explain the purpose of the online redo log files.

  • Outline the structure of the online redo log files.

  • Control log switches and checkpoints.

  • Multiplex and maintain online redo log files.

  • Manage online redo log files with Oracle Managed files (OMF).

Redo log files are Oracle's way to record all the changes made to the data in the database to provide the ability to recover from media failure or system failure in the database, in the instance, or on the server on which they are running. This chapter provides information on redo log files, their maintenance, and where to gather information concerning them.

Redo log files are organized into groups. At least two groups are required for an Oracle database and its instance, each group having at least one member. The next section provides information concerning the purpose of the redo log files.


Purpose of Online Redo Log Files

Redo log files provide a means and a mechanism for allowing Oracle to redo transactions in the event of a database failure. Every transaction that occurs that alters data in any way on the database (other than transactions such as direct loads, direct reads, and loads that are done with NOLOGGING option) is written synchronously to the redo log files to provide a recovery mechanism in the case of media or other system failure. This includes even transactions that have not been committed, undo segment information, and any schema and object management statements for objects in the database.

Redo log files are used in situations where instances fail. They are used so that you can recover data that had already been committed but that had never made it as far as being written out to the data files. The redo log files are used only for recovery purposes.

The following section looks at the structure of the redo log files and the redo log groups.


Structure of Online Redo Log Files

Figure 9.1 shows a possible configuration of online redo log files. Notice that the groups are associated with their members and that the members are each on different disks. Also, the arrows show you how log writer cycles through the groups as it performs its processing.

Figure 9.1. Redo log groups.

You, as the database administrator (DBA), can set up the Oracle database to maintain copies of online redo log files to avoid losing database information due to a single point of failure. This is the same premise used to suggest multiplexing of control files.

Online Redo Log Groups

Online redo log groups are a set of identical copies of the online redo log files. Each set is called an online redo log group. The LGWR background process is responsible for concurrently writing the same information to all the online redo log files in a group. Because these groups are used circularly by the instance processes, it is critical that there be at least two active online redo log groups for normal operation of the database.

Online Redo Log Members

Each online redo log file in a group is known as a member. Each member in a group has an identical log sequence number and an identical size. The sequence number is assigned every time that the Oracle Server starts writing to the log group and is used to identify each log file uniquely. The current log sequence number is stored in the control file and in the header of every data file in the database.

Creating the Initial Redo Log Files

The initial set of online redo log groups and their members is created during the creation of the database. The creation of these log files is governed by the following parameters in the CREATE DATABASE command:

  • MAXLOGFILES specifies the absolute maximum number of redo log groups that can be associated with the database. The default and maximum values for MAXLOGFILES are operating system dependent.

  • MAXLOGMEMBERS determines the maximum number of members to be allowed per group. Again, the default and maximum values allowed are operating system dependent.

It is important to understand that the "files" part of the MAXLOGFILES parameter in the CREATE DATABASE command does not refer to the redo log files that are the members, but rather to the set of files that make up a group. This is because it is not strictly necessary to multiplex the redo log file members in the group. MAXLOGFILES can refer to a single file, but if you do multiplex them, it can also refer to groups of more than one file.

Now that we understand the structure of the redo log groups and the members, the next section covers how these logs work.

How Redo Logs Work

Redo logs are cyclic in fashion and function, and each group is identified by a sequence number that is overwritten each time that log is reused. When one redo log file is full, LGWR moves on to the next group. This change from one group to the next is called a log switch. At this time, a checkpoint operation also occurs in the instance, and information is concurrently written out to the control file concerning the new log number. Log writer writes under the following conditions:

  • When a transaction commits

  • When the redo log buffers in the SGA become one-third full, reach 1MB in size, or, if neither of these conditions is met, every 3 seconds

  • Before DBW n writes out the modified blocks in the database buffer cache to the data files

Now we will look at the process of log switching and checkpointing as it relates to the online redo log files.


Control Log Switches and Checkpoints

As a DBA, it is important for you to know how to control log switches and checkpoint frequency. This section provides information on how to do this.

Log Switches

Log writer writes to the online redo log files sequentially. When the current active online redo log group is filled, log writer begins writing to the next group. This is called a log switch. When the last online redo log available is filled, LGWR returns to the first redo log group and starts the process all over again.

Checkpoints

During a checkpoint, a number of dirty database buffers (buffers whose contents haven't yet been written out to disk) covered by the redo log file that is being checkpointed are written to the data files by DBW n. This number of dirty database buffers is determined by the value set to the FAST_START_MTTR_TARGET initialization parameter. This initialization parameter is covered in greater detail in preparation for the Oracle 9i DBA Fundamentals II test.

The checkpoint is handled by the CKPT background process that updates all the headers on all the data files and control files to reflect that the checkpoint has completed successfully.

A checkpoint occurs at the following times:

  • At every log switch

  • Whenever the instance shuts down normally, transactionally, or immediately

  • Whenever forced by the setting of the FAST_START_MTTR_TARGET

  • When manually requested by the DBA

  • Whenever an ALTER TABLESPACE command is run with any one of the following options: OFFLINE NORMAL, READ ONLY, or BEGIN BACKUP

Information concerning every checkpoint is recorded in the alert_SID.log file in the BACKGROUND_DUMP_DEST location if the LOG_CHECKPOINTS_TO_ALERT initialization parameter is set to trUE. The default is FALSE for this parameter because it could make the alert log prohibitively large if every checkpoint were to be written out. This default behavior can be changed if you have a reason to do so.

Force Log Switch

Log switches are done automatically periodically, but as a DBA you can force a log switch to occur with the ALTER SYSTEM command as follows:

ALTER SYSTEM SWITCH LOGFILE;

Force Checkpoint

Checkpoints are also done automatically periodically by the database but can be forced using either the FAST_START_MTTR_TARGET parameter or the ALTER SYSTEM command as follows:

ALTER SYSTEM CHECKPOINT;

FAST_START_MTTR_TARGET is a centralized means of controlling the deprecated parameters FAST_START_IO_TARGET and LOG_CHECKPOINT_TIMEOUT.

FAST_START_MTTR_TARGET=500 means that instance recovery should not take more than 500 total seconds. The database adjusts other parameters behind the scenes to accomplish this goal.

FAST_START_IO_TARGET and LOG_CHECKPOINT_TIMEOUT must not be used if you are using the FAST_START_MTTR_TARGET parameter.

Now that you understand how to control log switches and checkpoints, we will look at multiplexing and maintaining the redo log files.


Multiplexing and Maintaining Online Redo Log Files

It is often desirable to add redo log file groups to the database to make sure that the first group is ready to be overwritten before the last group is full. This can often happen if a great deal of activity occurs on the database, and the database is in ARCHIVELOG mode.

To add a group to a database that has two redo log file groups, you would issue an ALTER DATABASE command as follows:

ALTER DATABASE ADD LOGFILE GROUP 3
('/mydatabases/mydb1/log3a.dbf', '/mydatabases2/mybd1/log3b.dbf')
SIZE 1M;

Or in Windows

ALTER DATABASE ADD LOGFILE GROUP 3
('c:\mydatabases\mydb1\log3a.dbf', 'd:\mydatabases2\mybd1\log3b.dbf')
SIZE 1M;

The generic format of the command is as follows:

ALTER DATABASE [database name]
ADD LOGFILE [GROUP integer] filespec, filespec;

All the information in the brackets is optional, and you would specify the name, location, and size with the filespec variable. The value required for use as the GROUP number can be selected and provided for each redo log file group that you want to add. If omitted, Oracle generates the value automatically.

Adding a Log File Member to a Group

Oracle, similar to its suggestions on control files, suggests that redo log files be multiplexed. To do this, Oracle allows you to use the ALTER DATABASE command to add the LOGFILE MEMBER. This is accomplished in Unix as follows:

ALTER DATABASE ADD LOGFILE MEMBER
'/mydatabases2/mybd1/log1b.dbf' TO GROUP 1
'/mydatabases2/mybd1/log2b.dbf' TO GROUP 2
'/mydatabases2/mybd1/log3b.dbf' TO GROUP 3;

It is important to fully specify the filename for the new members; otherwise, Oracle places the files in the default directory of the database server. If a file by the name that you have specified already exists, it must have the same size as the existing file for the GROUP specified, and you must specify the REUSE option; otherwise, the command fails.

But how do you determine how many redo log files you need for your database situation?

Optimum Number of Online Redo Log Files

Determining the appropriate number of online redo log groups for your given database instance can be an exercise in creativity. You simply need to test different configurations to determine what is needed for your database.

In some cases, a database instance may indeed only require two groups. Other situations may mean that additional groups are needed to guarantee that the groups will always be available to LGWR to use. You will start to see messages in the LGWR trace files and in the alert file that indicate that LGWR has started to have to wait. It will wait for available groups because checkpoints have not completed, or archival of the log file has not completed. At this point, the log groups need LGWR processing that can't occur until there are freed other groups. If this happens, it is time to add additional redo log groups to the database.

Although it is possible, with the Oracle server, to have multiplexed redo log file groups with different numbers of members in each group, it is better to try to maintain a symmetric configuration. Having different numbers of files in different groups should be only maintained as a temporary result of some unintended event (such as disk failure or other accidental situation).

Location, Location, Location

When you multiplex the online redo log files, you need to be sure to place the members on different disks or different groups of disks. By splitting up members like this, you are less likely to have a database crash because an entire group is unavailable in case of a loss of a disk.

Also, separating archive log files from the location of the online redo log files and placing these on different disks or disk groups reduces contention between the ARC n process and the LGWR process.

Ideally, redo log files should also be placed on different disks or disk groups than data files to reduce the possibility of contention between LGWR and DBW n, as well as to reduce the chances of losing both redo log files and data files in case of a loss of a disk or disk group.

Sizing the Redo Log Files

Although the minimum size for online redo log files is 50KB, the maximum size is operating system specific. Members of different GROUPS can have different sizes, although there is no real benefit to having different sized groups. Each member of a given group has to have the same size as the other members of that group.

The following situations will help to guide you in determining whether you have the right number of online redo log files:

  • If you have many log switches and checkpoints during a given time period, you may want larger redo log members.

  • If you have frequent log switches, you may want larger redo log members.

  • If you only see log switches and checkpoints when the database is shut down, you may want smaller redo log members.

  • If you see several points where the Archiver or Checkpoint has to wait to perform its activities until the log file is available, you may want to add one or more redo log groups.

  • You are starting to see many "checkpoint not complete" messages in your alert logs.

Dropping Redo Log Groups

If you need to resize (either increase or decrease the size of) redo log groups, or you want to replace the existing redo log groups with redo log groups of a different size, you need to have the ability to drop the existing redo log groups.

Before you can drop the existing log groups (at least before you can drop the last two), you have to have replacements built for them.

To drop a log file, or a redo log group, you use the ALTER DATABASE command as follows:

ALTER DATABASE [database name]
DROP LOGFILE {GROUP integer| ('filename', 'filename'...)}

The restrictions associated with dropping redo log groups are as follows:

  • An instance always requires at least two active groups of online redo log files.

  • An active or current group cannot be dropped (ALTER DATABASE SWITCH LOGFILE can allow the group in question to no longer be active or current).

  • When the online redo log group is dropped, the associated operating system files are not deleted.

You can drop a log member, as well as an entire group. It is appropriate to do this when the online redo log member is corrupt or unusable:

ALTER DATABASE DROP LOGFILE MEMBER <logfile name>;

There are, of course, the following restrictions to this, as well:

  • The log member to drop cannot be the last valid member of the group.

  • If the group to which the member is associated is the active or current group, you have to manually execute a log switch to drop the offending member.

  • If the database is in ARCHIVELOG mode, and the log file group to which the log member is associated has not yet been archived, the member cannot be dropped.

  • If the online redo log member is dropped, you still need to drop the operating system file to which it was associated.

Clearing Online Redo Logs

Occasionally, but fortunately not often, a redo log group will become corrupt, and all the members will be corrupt. As DBA, it falls to you to solve the problem by reinitializing the log group associated with the corruption.

Reinitialization can be accomplished through an ALTER DATBASE command as in the following example:

ALTER DATABASE CLEAR LOGFILE GROUP 2;

The generic form of the command follows:

ALTER DATABASE [database name]
CLEAR [UNARCHIVED] LOGFILE
{GROUP | (FILENAME, FILENAME)}

If your database is in ARCHIVELOG mode, and the corrupt redo log group hasn't yet been archived, you will need to use the UNARCHVIED parameter.

Using this command has the net effect similar to having added an online redo log group and dropped an offending online redo log group but can be issued even if only two groups are associated with the database.

You can clear an online redo log file whether or not it has already been archived. If it has not been archived, you must include the keyword UNARCHIVED in the ALTER DATABASE CLEAR LOGFILE command. This renders your backups unusable if the redo log file is needed for recovery. For this reason, you should take a backup of the database as soon as possible.

Relocating and Renaming Online Redo Logs

You can change the location and name of the online redo log files by adding new log files and dropping the old log files. Alternatively, you can use the ALTER DATABASE RENAME FILE command. Using this alternative method requires the database to be STARTUP MOUNT but not opened and is therefore impractical for a database that is running. It is usually much easier to add new redo log files and drop the old ones.

We have dealt with the management and maintenance of redo log files in a non-OMF database, but now we will look at their maintenance in a database that is managed using Oracle Managed Files (OMF).


Using OEM to Maintain Redo Log Groups and Members

Because Oracle Enterprise Manager (OEM) is the universal tool for maintaining the database, you can use it to help you maintain the online redo log groups associated with your database.

Adding Redo Log Groups

From the OEM console, expand your target working database from the Database folder, expand the Storage folder associated with that database, and right-click the Redo Log Groups folder from the navigator tree. Select Create from the resulting pop-up screen.

Enter the redo log group information on the screen that launches, specify the members that you want to associate with the group, and click Create.

Dropping Redo Log Groups

You can drop redo log groups and redo log members similarly through the Enterprise Manager interface.

Expand your chosen database from the Database folder, expand its Storage folder, and under its Storage folder, select the Redo Log Group that you want to remove. Right-click on the selected object, and select Remove to remove the group.

Relocating and Renaming Redo Log Members

From a launched OEM console, expand the database you want to maintain, and expand the Storage folder from the list. Next, expand the Redo Log Groups folder and, from within the folder, the group you want to maintain. Modify the redo log member information in the listing to rename or relocate the members in question and click Apply.


Managing Redo Log Files with OMF

With OMF, maintenance of the redo log files is simplified. Complete groups can be added with no file specifications provided simply with the following command:

ALTER DATABASE ADD LOGFILE;

To take advantage of this feature, you need to have the DB_CREATE_ONLINE_LOG_DEST_n initialization parameter set. To take advantage of duplexing the redo log files, you need not only DB_CREATE_ONLINE_LOG_DEST_1 to be set but also DB_CREATE_ONLINE_LOG_DEST_2 (more if you are going to be placing members on more than two different devices).

If a group is dropped, all the corresponding OMF files are dropped at the operating system level.

Archived redo log files cannot be OMF files. A specific file system location needs to be created specifically for archived log files. These locations are specified by the LOG_ARCHIVE_DEST_n parameter.

Now we have information on how redo log files work, how to create more, and how to delete existing ones. We also understand about sizing and configuration. But we still need to find out information on the redo log files in the database. The next section helps you with this task.


Data Dictionary Redo Information

Information concerning online redo log files, groups, and members can be obtained by querying the data dictionary. The following views provide information about both your online redo log files and your archived redo log files:

  • V$LOG Contains information about the redo logs from the control file.

  • V$LOG_HISTORY Contains information concerning archived redo logs from the control file. From here you can find the System Change Number (SCN) view of the archived log files.

  • V$LOGFILES This view provides the current status of all the redo logs.

  • V$LOGHIST This view contains information about the redo log file history from the control file.


Archived Redo Log Files

Filled redo log files can, optionally, be archived. One of the most important decisions that any DBA has to make is whether to configure the database to operate in ARCHIVELOG mode or NOARCHIVELOG mode.

NOARCHIVELOG Mode

If your database is running in NOARCHIVELOG mode, as the online redo log files are cycled, they are overwritten automatically. LGWR does not overwrite the redo log group until a checkpoint has been completed, but it does not have to incur the added overhead of having to allow the archiving of the redo log groups before the groups can be overwritten. This limits the amount of overhead that has to occur on a log switch.

Typically, you only want to run a database in NOARVHIVELOG mode if you are sure that you can recover the database in a reasonable amount of time from existing backups without significant data loss. Usually, this is in a data warehouse environment where there is little change other than bulk loads.

ARCHIVELOG Mode

ARCHIVELOG mode is when the database is configured to archive filled and inactive groups of online redo logs to an alternative location. There are two basic advantages to archiving redo log files and running your database in ARCHIVELOG mode: backup and recovery. All the changes made to the database are recorded in the online redo log files. This means that you can physically back up the database and all the archived redo logs and recover the database to the most recently committed transaction, or to any point in time without losing a single committed transaction.

There are two reasons that a database should be run in ARCHIVELOG mode:

  • A full database backup can be performed while the database is operational if the database is in ARCHIVELOG mode.

  • A database backup together with the online archived redo log files guarantee that you can recover your database to the last committed transaction.

You can archive redo log files either automatically or manually. For normal operation of the database, it is recommended that you allow the redo log files to be automatically archived and only manually archive a redo log file in special circumstances (for example, immediately before completing a hot backup).

LOG_ARCHIVE_START

The LOG_ARCHIVE_START initialization parameter controls whether archiving should be automatic when the instance starts up. Setting this parameter to trUE indicates that you want archiving to be automatic and causes the ARC n background process to initiate the archiving of filled online redo log groups every time there is a log switch. Setting LOG_ARCHIVE_START to FALSE (the default value) indicates that the DBA will archive the filled redo log files manually (in an active database, this can become a full time job). The DBA must manually execute a command each time he wants to archive an online redo log file and can archive all of them at once, or individually.

Archiving of redo log files is accomplished through the ARCn (Archiver) background process, or it is done manually through SQL statements.

To manually archive the redo log files, you would simply enter the following command:

ALTER SYSTEM ARCHIVE LOG ALL;

An entry is made in the control file every time an online redo log is archived. This entry contains the archive log name, the log sequence number, and the high and low System Change Number for the online redo log that has just been archived.

When the database is running in ARCHIVELOG mode, a filled online redo log file cannot be reused until a checkpoint has been taken and the redo log file has been backed up by the ARCn process. If the ARCn process cannot complete the archival process, and all the online redo log files fill up, the database will not crash but will not allow any more processing to be done until the ARCn process has started back up and cleared at least one online redo log file so that a log switch can occur.

Archived redo log files can be multiplexed, but all archived redo log files must be maintained by the DBA. This means that it is up to you to make sure that the directories don't fill up, that the files are protected from deliberate or accidental tampering, and that they are available whenever they are needed for instance and database recovery or restoration.

Archiving is covered in considerable detail in preparation for the OCP DBA Fundamentals II exam.

Archiver Information in the Data Dictionary

Information on the archive logs can be obtained by querying V$INSTANCE as shown in the following example:

SELECT archiver FROM V$INSTANCE;

Because we already know that we can get most any information from OEM, it seems logical to assume that we can get Archiver information from there, as well. Let's see how.

Obtaining Archiver Information from OEM

If you want to use OEM to obtain information about archived redo log files, you can open a launched console and expand your chosen database from the Databases folder. Expand the Instance in the navigator tree and click Configuration. Click on the Recovery tab in the detail side of the Console to obtain full information on the archived redo log files.


Exam Prep Questions

1:

What is the name of the background process that writes the online redo log files out to the archive logs when the database is running in ARCHIVELOG mode?

  • A. ARC n

  • B. DBW n

  • C. LGWR

  • D. CKPT

A1:

Answer A is correct. Archiver (or ARC n) is responsible for archiving the redo log files. Answer B is incorrect because Database Writer (DBW n) is responsible for writing the dirty buffers out to the data files. Answer C is incorrect because Log Writer (LGWR) is responsible for taking care of the online redo log files but not the archived redo log files. Answer D is incorrect because checkpoint has nothing to do with archive logs but is key in telling DBW n when to write out the dirty buffers.

2:

What is the name of the single parameter that you set in Oracle 9i to control the frequency of checkpoints in your instance?

  • A. FAST_START_MTTR_TARGET

  • B. LOG_CHECKPOINT_INTERVAL

  • C. LOG_CHECKPOINT_TIMEOUT

  • D. LOG_CHECKPOINT_TARGET

A2:

Answer A is correct. The single parameter that you would set in the initialization file is FAST_START_MTTR_TARGET. Answer B is incorrect because LOG_CHECKPOINT_INTERVAL is part of what makes up FAST_START_MTTR_TARGET and was one of the components that controlled checkpointing frequency in Oracle 8i. Answer C is incorrect because LOG_CHECKPOINT_TIMEOUT is part of what makes up FAST_START_MTTR_TARGET and was one of the components that controlled checkpointing frequency in Oracle 8i. Answer D is incorrect because it is a nonexistent parameter.

3:

How can you reduce the frequency of checkpoints and log switches in your database without impacting the initialization files?

  • A. Decrease the size of the online redo log files.

  • B. Increase the size of the online redo log files.

  • C. Increase the number of LGWR processes running.

  • D. Increase the number of ARC n processes running.

A3:

Answer B is correct. If you want to reduce the frequency of log switches and checkpointing without any impact to the initialization files, you would need to increase the size of the online redo log files. Answer A is incorrect; decreasing the size of the online redo log files would cause them to log switch more often. Answer C is incorrect because there is no way to increase the number of log writer processes that are running on an instance. Answer D is incorrect because archiver processes have no effect on the frequency of log switches or checkpointing.

4:

Oracle recommends that you multiplex your redo log members in each online redo log group. What is the reason for this recommendation?

  • A. So that DBW n can write more efficiently

  • B. To eliminate contention between LGWR and ARC n in archiving

  • C. To eliminate a possible single point of failure

  • D. So that there isn't contention between writing to the online redo log files and the control files

A4:

Answer C is correct. You want to multiplex redo log group members for the same reason that you want to multiplex control files: to limit the places where you have a single point of failure in the database and instance. Answer A is incorrect because multiplexing redo log files has no net effect on database writer processes. Answer B is incorrect because eliminating contention between LGWR and ARC n is not a reason to multiplex. If contention will occur, it will occur regardless of how many copies of the redo logs are available. Answer D is incorrect because log writer is the process that writes to the online redo log files and not to the control files, so there is a limited possibility of having contention between the two.

5:

You want to use OMF for maintaining and naming your online redo log files. What is the name of the initialization parameter that allows you to do this?

  • A. LOG_ARCHIVE_DEST_n

  • B. FAST_START_MTTR_TARGET

  • C. LOG_CHECKPOINT_INTERVAL

  • D. LOG_FILE_DEST_n

  • E. LOG_CHECKPOINT_TARGET

A5:

Answer A is correct. LOG_ARCHIVE_DEST_n is the initialization parameter that controls the location and naming of the online redo log files (as well as the control files) in an OMF managed database. Answer B is incorrect. FAST_START_MTTR_TARGET controls how often checkpoints occur, not where the redo log files are written. Answer C is incorrect. LOG_CHECKPOINT_INTERVAL is one of the Oracle 8i parameters that controlled checkpointing. Answer D is incorrect because LOG_FILE_DEST_n is not an Oracle 9i parameter. Answer E is incorrect because LOG_CHECKPOINT_TARGET is one of the Oracle 8i parameters that controls checkpointing frequency.

6:

By default, checkpoints happen at least as often as what? [check all that apply]

  • A. DBW n writes dirty buffers out to files.

  • B. Redo log switches.

  • C. Redo logs are archived.

  • D. As the DBA forces the checkpoint.

A6:

Answers B and D are correct. Checkpoints happen at least as often as redo log switches and at least as often as the DBA manually forces the checkpointing. Answer A is incorrect, technically, because checkpointing causes DBW n to write its dirty buffers out to file. Answer C is incorrect because there is no direct correlation between the frequency of checkpointing and archiving.

7:

Which data dictionary view gives you information on the history of your online redo log files?

  • A. V$LOG

  • B. V$LOGHIST

  • C. V$REDOLOG

  • D. V$LOGFILE

  • E. V$LOG_HISTORY

A7:

Answer B is correct. You can find information on the history of your online redo log files in the V$LOGHIST view. Answer A is incorrect; V$LOG contains information from the control file on the redo log files. Answer C is incorrect because V$REDOLOG is not a V$ view in the Oracle 9i data dictionary. Answer D is incorrect because V$LOGFILE provides the current status of the redo log files in the instance. Answer E is incorrect; V$LOG_HISTORY gives you a history of the archived redo log files.

8:

You want to limit contention on the different log members in your online redo log file groups. Which would be the best way (and the Oracle recommended way) to customize your configuration?

  • A. Put the online redo log members on the same disk to reduce I/O contention.

  • B. Put the online redo log members on different disks to reduce I/O contention.

  • C. Put all the redo log members on the same disk as the archived redo logs to reduce contention.

  • D. Have only redo log members in each online redo log group to reduce contention.

A8:

Answer B is correct. To limit potential I/O contention you need to put the different redo log members on different disks or disk groups. Answer A is incorrect; putting the members on the same disk increases the chance of contention. Answer C is incorrect because putting not only all the redo log members on the same disk but also all the archive logs on the same disk as the redo log members increases the chance of I/O contention even further. Answer D is technically incorrect because Oracle recommends that you multiplex online redo log files.

9:

When is a valid time to be running in ARCHIVELOG mode?

  • A. When you want to be able to take backups while the database is running.

  • B. When you want to save time and overhead by only running in ARCHIVELOG mode at night when the system is quiet.

  • C. When you are running a data warehouse and the only updates are taking place as bulk loads.

  • D. When your database is high volume and you don't want to impact users by adding background processes to the instance needlessly.

A9:

Answer A is correct. One of the primary reasons to run your database in ARCHIVELOG mode is to be able to take online backups (or hot backups) of your database. Answer B is incorrect because archiving only when there is limited activity defeats the purpose for running in this manner. Answer C is incorrect because you can reload the data warehouse, and it is one place where running in NOARCHIVELOG mode is fairly safe. Answer D is incorrect because, if you have a high-volume database, you would likely want to be running in ARCHIVELOG mode so that you could recover any information in case of a failure.

10:

What is the command to manually archive the online redo log files?

  • A. ALTER SYSTEM ARCHIVE LOG ALL;

  • B. ALTER DATABASE ARCHIVE LOG ALL;

  • C. ALTER REDO_LOGS ARCHIVE LOG ALL;

  • D. ALTER SYSTEM ARCHIVE LOG ALL REDO_LOGS;

A10:

Answer A is correct; to manually archive the redo log files, you enter the ALTER SYSTEM ARCHIVE LOG ALL; command.


Chapter 10. Managing Tablespaces and Data Files

Terms you'll need to understand:

  • DBA_TABLESPACES

  • V$TABLESPACES

  • DBA_DATA_FILES

  • V$DATAFILE

  • DBA_TEMP_FILES

  • V$TEMPFILE

  • CREATE TABLESPACE

  • ALTER TABLESPACE

  • ALTER DATABASE

Concepts you'll need to master:

  • Describe the logical structure of the database.

  • Create tablespaces.

  • Alter the size of an existing database.

  • Allocate space for temporary segments.

  • Change the status of tablespaces.

  • Change storage settings of tablespaces.

  • Implement tablespaces with Oracle Managed Files.

All databases are made up of one or more tablespaces. The single absolutely required tablespace is the SYSTEM tablespace; however, typically many other tablespaces are associated in the database. This chapter addresses the creation, deletion, and maintenance of the tablespaces associated with the database.

Although it is technically true that you really need only the SYSTEM tablespace to have a functional database, it is also true that Oracle suggests that you not store user data in the SYSTEM tablespace. So if you want a functional database, you really don't have much choice but to create additional tablespaces. The addition of more tablespaces gives you more flexibility in administration operations and reduces contention on the data dictionary objects, schema objects, or for the same data files. In this chapter, we look at the creation and maintenance of tablespaces and their data files and the issues surrounding them.


Logical Structure of the Database

As a DBA, you can create new tablespaces, resize data files associated to the tablespaces, add files to tablespaces, set default segment storage settings, alter default segment storage settings, make tablespaces read-only or read-write, make tablespaces temporary or permanent, and drop tablespaces.

Recall that the database architecture includes both the logical structure (tablespaces, segments, extents, and data blocks) and the physical structure (control files, online redo log files, and data files).

The Oracle Server enables the DBA to maintain fine-grained control of disk space through the use of the logical structures.

The logical structures tablespaces, extents, and segments are the means by which the DBA manipulates the data file physical structure.

Figure 10.1 shows the relationship between the different logical and physical storage structures in the Oracle database and instance. Note that there is a one-to-many relationship between the database and tablespaces, between tablespaces and extents, between extents and Oracle blocks, between tablespaces and data files, between Oracle blocks and OS blocks, and between data files and OS blocks. These relationships can extend even further because the data files can be spread across different file systems, disks, and disk groups.

Figure 10.1. Logical and physical configuration of the database.

Shown in Figure 10.1, although not covered in this chapter, are the control files and the online redo log files in the physical part of the database.

Redo log files are covered in Chapter 9, "Maintaining Redo Log Files," and control files are discussed in Chapter 8, "Maintaining Control Files."

The following list provides some of the outstanding characteristics of tablespaces:

  • The data in an Oracle database is stored in a tablespace. The database has to exist before any tablespaces other than the SYSTEM tablespace (which is created concurrently with the creation of the database) can be created.

  • Tablespaces are logically grouped areas of space that allow you to store and regulate the data within the database at its most coarse, granular level.

  • Tablespaces can belong to exactly one database at a time, and each tablespace can consist of one or more operating system files, which are called from the Oracle perspective data files.

  • Any given tablespace may contain zero, one, or more than one segment.

  • Tablespaces can be brought online only when the database is running.

  • With the notable exceptions of the SYSTEM tablespace, temporary tablespaces, and an undo tablespace with active undo segments, tablespaces can be taken offline while the database is running without causing harm to the database.

  • Tablespaces can be switched between read-only and read-write status whenever necessary without deleterious effect to the database to which they are associated.

The following list provides some of the outstanding characteristics of data files:

  • Tablespaces consist of one or more data files.

  • Data files are physical constructs that conform to the operating system requirements on which the Oracle Server is running.

  • A data file can belong to exactly one tablespace, although more than one data file can belong to the same tablespace.

  • Oracle creates the data file on the operating system by allocating the specified amount of disk space to the data file plus a small amount of overhead that only Oracle can use.

  • The database administrator is the only one who can change the size of a data file after its creation unless it has been specified (through the AUTOEXTEND clause) that the data file can grow dynamically until it fills the entire file system.

The following list provides some of the outstanding characteristics of segments:

  • A segment is the space allocated for a specific logical storage structure within a tablespace. All the storage allocated to a table is in that table's segment. All the storage allocated to an index is in that index's segment.

  • A tablespace may contain zero, one, or more than one segment.

  • A segment cannot span multiple tablespaces.

  • A segment can span multiple data files as long as those data files belong to the same tablespace.

  • Each segment is made up of one or more than one extent.

The following list provides some of the outstanding characteristics of extents:

  • Space is allocated to segments by extents.

  • One or more extents make up a segment.

  • When a segment is created it must have at least one extent.

  • As a segment grows, extents are added to the segment.

  • You, as a DBA, can add extents to segments.

  • Extents are a set of contiguous Oracle blocks.

  • An extent cannot span segments, tablespaces, or data files.

The following list provides some of the outstanding characteristics of data blocks:

  • Oracle manages storage space, at the lowest granularity, in units called Oracle blocks or data blocks.

  • At the finest level of granularity, all data is stored in an Oracle database in data blocks.

  • Data blocks are the smallest unit of storage that Oracle can allocate, read from, or write to.

  • One data block corresponds to one or more than one operating system blocks that are allocated from exactly one existing data file.

  • The standard block size for an Oracle database is specified by the DB_BLOCK_SIZE initialization parameter and is set when the database is created. Because in Oracle 9i this is only the default block size. Tablespaces of nonstandard block sizes can be created using the CREATE TABLESPACE statement and at the same time specifying the BLOCKSIZE clause. These nonstandard block sizes can be given any of the following vales: 2KB, 4KB, 8KB, 16KB, or 32KB. However, to be able to use nonstandard block sizes in tablespaces, you must first configure a subcache within the buffer cache area of the SGA for each of the nonstandard block sizes that you intend to use. These subcaches are configured in the PFILE or the SPFILE and are as follows:

    • DB_2K_CACHE_SIZE

    • DB_4K_CACHE_SIZE

    • DB_8K_CACHE_SIZE

    • DB_16K_CACHE_SIZE

    • DB_32K_CACHE_SIZE

  • Data block size should be a multiple of the operating system's block size to avoid unnecessary I/O operations.

  • Maximum data block sizes are operating system dependent.

Now that we have looked at the logical structure of the database, including tablespaces, in the next section we will look at how to manage the status of tablespaces.

Managing Tablespace Status

Tablespaces can have several different statuses. In the following sections, we will discuss online status (also considered to be read/write), offline status, and read-only status. These statuses are used for different reasons and can be used on the same tablespace at different times.

Offline or Online

Tablespaces typically need to be online so that the data in the tablespaces is available. There are often reasons that you want to take a tablespace offline. When a tablespace has an offline status, it is not available for data access. No SQL statements can reference objects contained in the tablespace, and anyone trying to access any objects in the offline tablespace receives an error. Several tablespaces can never have an offline status: SYSTEM tablespace, default temporary tablespace, and an undo tablespace with active undo segments.

You might want to take a tablespace offline to make a portion of the database unavailable while allowing normal access to the remainder of the database. You might do this to take an offline backup, to recover a tablespace or one or more of its data files while the database remains open and operable, or to move a data file while allowing the rest of the database to be open.

The following command takes the tablespace mydata offline:

ALTER TABLESPACE mydata OFFLINE;

You can specify several different parameters for the offline statement. Those parameters, and their meanings, can be found in the following list:

  • NORMAL This is the default and need not be specified. Flushes all the blocks in all the data files in the tablespace out of the SGA. If you offline a tablespace NORMAL, you do not need to perform media recovery when you bring it back online. This is the preferred means of offlining a tablespace if at all possible.

  • TEMPORARY Performs a checkpoint for all the online data files in this given tablespace only. Offline files may require media recovery.

  • IMMEDIATE Does not ensure that any of the data files associated with the tablespace are available, and Oracle does not perform a checkpoint. You have to perform media recovery on the tablespace before you can bring it back online.

  • FOR RECOVER Allows the tablespace to be taken offline to enable tablespace point-in-time recovery.

When the tablespace is taken offline, all of that tablespace's associated data files are also taken offline. To bring the tablespace and its data files back online, you would issue the following command:

ALTER TABLESPACE mydata ONLINE;

Whenever a tablespace goes offline or comes back online, an event is recorded in the data dictionary so that Oracle can remember that the tablespace is offline. An event is also recorded in the control file.

If you shut down the database with a tablespace in offline state, it will remain offline, and when the database restarts (in the mount and open portions of the open), the offline tablespace is not checked.

Read-Only

Not only can a tablespace be online or offline, it can also be made to be read-only. Read-only tablespaces are made available to users with only read operations possible, although objects can be dropped from read-only tablespaces. Dropped objects are possible because the data dictionary is the only thing updated in the drop. For locally managed tablespaces, the segments connected to the dropped objects are made into temporary segments to prevent the bitmap from being updated.

When the tablespace is made read-only, it is first placed into a transitionally read-only state. During this period, no more write operations are permitted, but any writes that had taken place can either be committed or rolled back. After the active transactions are committed or are rolled back, the tablespace is fully placed in read-only mode.

Even more interesting, you can create a read-only tablespace on a drive with removable media.

After you have altered the tablespace to read-only with the following command, you can move the data file to a Write Once Read Many (WORM) device (such as a CD or DVD):

ALTER TABLESPACE mydata READ ONLY;
Cp d:\mydatabase\mydb1\mydata01.dbf e:\dvddrive\mydata01.dbf

ALTER TABLESPACE mydata RENAME DATAFILE 'e:\dvddrive\mydata01.dbf\;

You can bring tablespaces that are read-only back into read-write status by means of another ALTER statement:

ALTER TABLESPACE mydata READ WRITE;

All data files connected to the read-only tablespace that you want to make read-write have to be online and available.

If you have moved the file from its original location to the WORM device, you will have to copy it off the WORM device to make the tablespace read-write.

You will have to first copy the data file back, then alter the database to look at the writable media's data file, and then make the tablespace read-write.

You now know the basic logical structure of a tablespace. The next section looks at the different kinds of tablespaces that follow those logical constructs.


Types of Tablespaces

DBAs create tablespaces for the ease of control and maintenance over the information and structures within the Oracle database. There are two types of tablespaces in an Oracle database: SYSTEM and everything else.

The SYSTEM tablespace is created when you create the database. Its purpose is to hold the data dictionary tables, views, and stored program units. It also holds the SYSTEM undo segment. User data should never be stored in the SYSTEM tablespace although as yet, there is nothing to stop you from doing it.

The non-SYSTEM tablespaces are created by the DBA to enable more control and flexibility in database administration.

Non-SYSTEM tablespaces allow you to separate UNDO information, temporary information, application data, and application indexes. You can use tablespaces to separate data by backup requirements, by the characteristic of static over dynamic data, and as a means to control the amount of space allocated to user's objects.

We have established that the best way to maintain your database is to create additional tablespaces after the database has been created. The next few sections address the ways that we can create these additional tablespaces.

Undo Tablespace

Undo tablespaces are Oracle 9i's preferred manner of storing undo segments. Undo tablespaces cannot contain anything other than undo segments, and Oracle alone has direct control over them.

When creating an undo tablespace, you can specify only the DATAFILE clause and the EXTENT MANAGEMENT clause.

You can find more information on undo tablespaces and the management of undo data in Chapter 11, "Managing Undo Data."

The CREATE TABLESPACE statement for undo tablespaces follows:

CREATE UNDO TABLESPACE mydb1_undo1
DATAFILE '/mydatabases/mydb1/mydb1_undo1.dbf' SIZE 100M;

Temporary Tablespaces

Oracle uses temporary tablespaces for sort operations. Like undo tablespaces, temporary tablespaces cannot contain any other type of data (undo tablespaces can't contain anything but undo data; temporary tablespaces cannot contain any permanent objects). Oracle highly recommends that you create temporary tablespaces as locally managed.

Sort segments (also known as temporary segments) are used when a segment is shared by multiple sort operations. Temporary tablespaces provide performance improvements when you have multiple sorts going on at one time that are too big to fit easily into memory. The sort segment in the temporary tablespace is created at the time of the first large sort operation in the instance. This segment expands by allocating extents until the segment is equal to or greater than the total storage demands of all the active sorts running in the given instance.

The following is an example of the CREATE TABLESPACE statement for temporary tablespaces:

CREATE TEMPORARY TABLESPACE mydb1_temp
TEMPFILE '/mydatabases/mydb1/mydb1_temp01.dbf' SIZE 1000M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M;

Temporary tablespaces have several unique features that differ from normal tablespaces. These unique features are as follows:

  • Temporary tablespaces are always created with NOLOGGING mode enabled.

  • Temporary tablespaces can never be set to read-only.

  • Temporary tablespaces' data files (known as tempfiles) can never be renamed.

  • Temporary segments are even necessary for read-only databases (in fact, they may be even more important for read-only databases). The necessity of temporary tablespaces in a read-only database is due to the need for manipulating data being retrieved and for creating structures, albeit transient structures, to support user queries. Sorting needs to be done on retrieved data, groupings and aggregations, and computation, all of which require temporary segments. Many of these things, particularly temporary tables, could be created in a read/write database in the user's default tablespace. There is nowhere in a read-only database to do these other than a temporary tablespace.

  • Temporary tablespaces are not recovered in media recovery.

  • BACKUP CONTROLFILE does not generate information for temporary tablespaces' tempfiles.

  • CREATE CONTROLFILE cannot specify information concerning temporary tablespaces and their tempfiles.

  • To optimize the performance of sorts, the temporary tablespaces' UNIFORM EXTENT SIZE should be used and should be a multiple of SORT_AREA_SIZE.

Default Temporary Tablespaces

Default temporary tablespaces allow you, as DBA, to specify a database wide default temporary tablespace. Having a default temporary tablespace eliminates the chances that an errant sort will use the SYSTEM tablespace for storing sort data. You can create the default temporary tablespace either with the CREATE DATABASE command or with the ALTER DATABASE command. When you create it with the CREATE DATABASE command, the default temporary tablespace is always locally managed.

If the database has a default temporary tablespace, all users created without the TEMPORARY TABLESPACE clause will have the defined default as their temporary tablespace. Without having a default temporary tablespace, those users would be created having the SYSTEM tablespace assigned as their default temporary tablespace.

To set a tablespace as the default temporary tablespace after the database has been created, you can run the following command:

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE mydb_temp1;

After the tablespace has been made the default temporary tablespace, users who do not have an explicitly assigned temporary tablespace will have that as theirs. The DEFAULT TEMPORARY TABLESPACE can be reassigned by use of the ALTER DATABASE command. After the ALTER DATABASE command has been successfully run, all users who have the DEFAULT TEMPORARY TABLESPACE assigned to them will have the new default assigned to them.

It is important to note that, if you create a temporary tablespace in this manner, there is a good chance that Oracle will understand that the tablespace is to be sized at the SIZE parameter. However, at the operating system level, it is not always created at this size but is created sparsely. If you are creating files in different file systems, you may allocate more space in a file system than actually exists in the file system. This can cause issues when the database tries to fill out those tempfiles later, if you don't take the additional space requirements into account.

But great as it is to be able to use default temporary tablespaces, there are restrictions on them. Those restrictions are as follows:

  • After you have defined a default temporary tablespace, it cannot be dropped until you have defined a new temporary tablespace.

  • It cannot be taken offline.

  • It cannot be made read-only.

  • You cannot alter the default temporary tablespace to make it a permanent tablespace.


Creating Tablespaces

You create tablespaces with the CREATE TABLESPACE command. The following is the generic form of the command with an explanation of the different components:

CREATE TABLESPACE tablespace_name
[DATAFILE clause]
[MINIMUM EXTENT integer [K]]
[BLOCKSIZE integer [K]]
[LOGGING | NOLOGGING]
[DEFAULT storage_clause]
[ONLINE | OFFLINE]
[PERMANENT | TEMPORARY]

  • Tablespace_name is the name of the tablespace that you want to create.

  • MINIMUM EXTENT allows you to ensure that every extent used in the tablespace is at least this size and is always a multiple of this size. You can specify this in either K for kilobytes or M for megabytes.

  • LOGGING, which is the default if not specified, tells Oracle that all tables, indexes, and partitions in this tablespace should have all changes written to the online redo log files. NOLOGGING specifies that all tables, partitions, and indexes in this tablespace should not have all their changes written to the online redo log files. NOLOGGING affects only certain DML and DDL commandsfor example, direct loads. This parameter can be overridden after the tablespace is created.

  • DEFAULT provides the default storage parameters for all the objects created in the tablespace. These defaults can be overridden.

  • ONLINE, the default, creates the tablespace online and available for users to start using immediately. OFFLINE makes the tablespace unavailable immediately, and users are not able to use it for storage until the DBA has brought it online.

  • PERMANENT, again the default, specifies that the tablespace can be used to hold permanent objects (tables, indexes, clusters). TEMPORARY signifies that the tablespace can be used only to hold temporary data and temporary objects. TEMPORARY tablespaces hold things such as the segments used by implicit sorts (ORDER BY, GROUP BY).

  • DATAFILE_clause is the fully qualified filename including the data filename, the location of the data file, the size that you want to have assigned to the data file, and the optional REUSE and AUTOEXTEND clauses to determine whether you want to reuse (REUSE clause) an existing data file or you want the data file to have the capability to automatically extend its storage (AUTOEXTEND) in order to not fill up.

We have now created tablespaces, but what if we want to get rid of a tablespace? What do we do then? The following section covers dropping tablespaces.


Dropping Tablespaces

To remove a tablespace from the data dictionary and therefore from the database, you need to drop that tablespace. In Oracle 9i, you can also drop the data file associated with the tablespace by specifying the AND DATAFILES clause:

DROP TABLESPACE mydb1data INCLUDING CONTENTS AND DATAFILES;

The following list provides all the possible parameters to the DROP TABLESPACE command along with the meanings of those parameters:

DROP TABLESPACE tablespacename
INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;

  • INCLUDING CONTENTS Causes all the segments in the tablespace to be dropped.

  • AND DATAFILES (or INCLUDING DATAFILES) Causes all the data files associated with the tablespace to be dropped from the operating system.

  • CASCADE CONSTRAINTS Causes all the referential integrity constraints from other tablespaces' tables that refer to primary and unique keys on the tables in the dropped tablespace to be themselves dropped.

  • tablespacename Name of the tablespace to be dropped. This parameter is required.

A tablespace that still contains data cannot be dropped without specifying the INCLUDING CONTENTS option. This can create significant undo information if the tablespace contains many objects. After the tablespace has been dropped, the data associated with that tablespace is no longer in the database. If you don't specify the AND DATAFILES parameter, only the pointers in the control files that reference the data files associated with the tablespace are dropped along with the associated data dictionary information. This means that the data files still exist and must be deleted explicitly with the appropriate operating system commands.

It is recommended that you take offline any tablespace that you intend to drop, even read-only tablespaces, so that no transactions are accessing the segments in the tablespace when the drop command is issued.


Space Management in Tablespaces

Tablespace extents can be managed either by the traditional (and still default) method, wherein the information concerning free space information for the tablespace resides in the data dictionary, or through use of locally maintained bitmaps. After you have chosen a space management method, it is not easy to alter this method later.

Locally Managed Tablespaces

A tablespace has the ability, in Oracle 9i, to manage its own extents in a bitmap inside each data file. It uses this mechanism to keep track of the free and used status of the blocks in the data file. Whenever a block is used or freed for reuse, Oracle changes the value of the bitmap to show the new status of the block.

Locally managed tablespaces store their free extent information in bitmap segments within the tablespace. Each bit in the bitmap corresponds to a block or to a group of blocks, and the value of the bit indicates that the blocks are free or used.

Because locally managed tablespaces control and track their free space usage within a bitmap within the data file, contention is significantly reduced on the data dictionary tables, and no undo is generated when space is allocated or deallocated. Recursive space management operations that occur in dictionary managed tablespaces when consuming or releasing extents result in contentions on data dictionary tables. Locally managed tablespaces automatically track adjacent free space, meaning that there is no longer any need to coalesce free space because it is all managed within the data file itself.

To create a locally managed tablespace, the LOCAL option of the EXTENT MANAGEMENT clause needs to be specified as follows:

EXTENT_MANAGEMENT [DICTIONARY | LOCAL [AUTOALLOCATE | UNIFORM [SIZE integer [K|M]]]

The options for the EXTENT MANAGEMENT clause are explained in the following list:

  • DICTIONARY specifies that the tablespace will be managed using the data dictionary tables.

  • LOCAL specifies that the tablespace will be managed using a bitmap. If you specify LOCAL, you cannot specify a DEFAULT storage clause or MINIMUM EXTENT.

  • AUTOALLOCATE specifies that the tablespace is system managed. You cannot specify an extent size if AUTOALLOCATE is specified, and AUTOALLOCATE is the default.

  • UNIFORM specifies that the tablespace is going to be managed with uniform extent size, with each extent the SIZE of bytes. (You can use either K for kilobytes or M for megabytes for the SIZE specification.) The default is 1 megabyte.

You can use the EXTENT MANAGEMENT clause in the CREATE TABLESPACE command for any tablespace that is not the SYSTEM tablespace (which you only indirectly create, anyway). For a temporary tablespace, you can specify EXTENT MANAGEMENT LOCAL in the CREATE TEMPORARY TABLESPACE command.

Dictionary Managed Tablespaces

Dictionary managed is the default method for creation of tablespaces. Free extents associated with the tablespace are recorded and managed in the data dictionary tables. Every segment in the tablespace, if the tablespace is dictionary managed, can have its own different storage clause. Oracle updates the appropriate tables in the data dictionary whenever an extent is allocated or deallocated in relation to the tablespace. Coalescing is required in frequently updated segments in dictionary managed tablespaces.

Now that we have a handle on dictionary versus locally managed and SYSTEM versus non-SYSTEM tablespaces, we will look at how to change the size and storage settings in tablespaces.


Changing the Size of the Tablespace

You use the ALTER TABLESPACE command to alter the default storage definition of a tablespace or to add a data file to it. The following is the generic command to alter the storage settings for a tablespace:

ALTER TABLESPACE tablespacename
[MINIMUM EXTENT integer [K|M]
[DEFAULT storage clause]

Only dictionary managed tablespaces can have their storage settings altered.

Resizing a Tablespace

To resize a tablespace, you can either add a new data file to that tablespace, or you can change the size of an existing data file (either automatically or manually).

Adding a data file can be accomplished with the following command:

ALTER TABLESPACE mydb1data ADD DATAFILE '\mydatabases\mydb1\mydb1data02.dbf' SIZE 100M;

Manually adjusting the size for a data file associated with a tablespace, you use the following ALTER DATABASE command:

ALTER DATABASE DATAFILE '\mydatabases\mydb1\mydb1data01.dbf' RESIZE 500M;

This command can be used to either grow or shrink tablespace data files. However, if any objects have storage above the specified size, the data file can only be decreased in size to the last block of the last object in the data file.

To allow the data file to extend itself automatically, you can simply turn on AUTOEXTEND and set a maximum size for the data file (this allows it to grow without allowing it to run the file system or the entire drive out of space):

ALTER DATABASE DATAFILE '\mydatabases\mydb1\mydb1data01.dbf' SIZE 250M
AUTOEXTEND ON NEXT 25M MAXSIZE 500M;

AUTOEXTEND either enables (on) or disables (off) the automatic extension of data files.

Optionally, you can set MAXSIZE to UNLIMITED if you are willing to keep an eye on the remaining space on the storage device on which the file exists to make sure that it does not completely run out of space to grow.

Moving Data Files with ALTER TABLESPACE

Often, instead of simply adjusting the size of a tablespace, you want to change the location for that tablespace's data files. This can be done to move a more active tablespace onto its own disk, or to spread I/O out across different disks.

To move a tablespace's data files, the tablespace must be offline, and the target data file or files must exist prior to the execution of the ALTER TABLESPACE command.

You can take the tablespace offline, copy the data files to the new location (then check to make sure that they are in the new location), execute the ALTER TABLESPACE command to use the new location, bring the tablespace back online, and then delete the original set of data files:

ALTER TABLESPACE mydb1data
RENAME DATAFILE '/mydatabases/mydb1/mydb1data01.dbf'
TO '/mydatabases3/mydb1/mydb1data01.dbf';

You cannot use this method to move the data files for the SYSTEM tablespace, the undo tablespace, and the temporary tablespace because the these tablespaces can never be taken offline.

Moving Data Files with ALTER DATABASE

An alternative method to move a tablespace's data files, and a method that can be used to move the data files associated with the SYSTEM tablespace, involves using the ALTER DATABASE command. Because the undo tablespaces and temporary tablespaces can also not be taken offline, this is the means that needs to be used to move the files associated with those tablespaces, as well.

To use this method, you need to shut down the database NORMAL or IMMEDIATE. After the database is shut down, you can use the operating system's commands to either copy or move the files associated with the tablespace involved. I usually copy the files; that way they are available if something weird happens in the process. After the files are in the new location, mount the database and issue the ALTER DATABASE RENAME FILE command as follows, and open the database after it is successful:

ALTER DATABASE mydb1
RENAME FILE '/mydatabases/mydb1/system01.dbf', '/mydatabases/mydb1/system02.dbf'
TO '/mydatabases3/mydb1/system01.dbf', '/mydatabases3/mydb1/system02.dbf';

Because Oracle Enterprise Manager (OEM) is a powerful tool, it is possible to maintain tablespaces and their data files using this tool. The next section gives you information on how this can be accomplished.


Manipulating Tablespaces and Data Files with OEM

As always, when maintaining anything with OEM, you have to attach to a launched console, expand the databases folder, and find the database from the list that you will be working with.

Because we are working with tablespaces and data files, and both are considered to be storage, you need to find and expand the storage section.

Changing the Storage Settings

To change the storage settings, you need to expand the tablespaces folder, find the tablespace to which you need to make alterations, and right-click the tablespace. From the resulting pop-up menu, choose View/Edit Details, click the storage tab in the popped-up window, make any changes that you need to make, and click the Apply button; then click OK. Alternatively, you can simply select the tablespace to which you need to make changes, select the storage tab, make the changes, click Apply, and then click OK. Figure 10.2 shows the screen details where this is accomplished.

Figure 10.2. Altering storage settings via OEM.

Creating a Temporary Tablespace

Right-click the Tablespaces folder and select Create from the pop-up menu. Supply the details for your new tablespace on the General tab (name of the new tablespace, filename, or tempfile namein this case, statusand type for the new tablespace). Because we are creating a temporary tablespace, select the Temporary radio button from the Type region of the window.

Select the Storage tab and enter the relevant storage information. This includes locally managed or managed in the dictionary and extent allocation (Uniform for locally managed or with override settings for dictionary managed).

Click the Create button to complete the creation of the temporary tablespace.

Figure 10.3 shows the screen through which you create a tablespace. The only difference in OEM between creating an undo tablespace, a temporary tablespace, and a regular tablespace is which radio button at the bottom of the screen you select.

Figure 10.3. Tablespace creation screen.

Bringing a Tablespace Offline or Online

Expand the Tablespaces folder and select the tablespace that you want to bring online or offline. In the General tab, select the Online or Offline radio button or the Read-Only block. If you are taking the tablespace offline, you need to select, from the drop-down list next to Offline, the mode you want to use to bring it offline (Normal, Temporary, Immediate, For Recover). Click Apply.

Dropping a Tablespace

Expand the Tablespaces folder and select the tablespace that you want to drop. From the Main menu at the top of the console, select Object and from the drop-down menu select Remove. A splash screen appears from which you verify that you really do want to drop the tablespace in question. The screen tells you that when you drop the tablespace, the stuff in it goes too. You can also select a check box that allows you to delete the data files associated with the tablespace from the operating system. Your choices are Yes (you really do want to drop the tablespace), No (you don't really want to drop it), or Help. Figure 10.4 shows the warning screen instructing you on Oracle's suggestions when dropping tablespaces. Notice that you can choose to drop the data files at the same time, or to not drop them.

Figure 10.4. Drop Tablespace OEM screen.

Enabling or Disabling AUTOEXTEND

Expand the Datafiles folder and select the data file that you want to alter. In the storage tab of the data file, you can select, or deselect, the Automatically Extend Datafile When Full (AUTOEXTEND) check box. If you are enabling AUTOEXTEND, you can set the increment value for the file (how many kilobytes or megabytes you want to be added to the file with each automatic extend) as well as the Maximum Size. Click Apply, and the data file's automatic extensibility is altered. Figure 10.5 shows the screen on which you can select, or deselect, the Autoextend option for an individual data file. When choosing to set a data file to automatically extend, you can give it the parameters of what increments you want it to increment in (kilobytes or megabytes) and what the maximum size you want it to be able to grow to (again, in kilobytes or megabytes).

Figure 10.5. OEMs Autoextend screen.

Be aware that if you don't change the default behavior that OEM provides, Unlimited will be set as the file's maximum size.

Adding a Data File

Expand the Tablespaces folder, find the tablespace that you need to add a data file to, and right-click on the tablespace (or just select the tablespace). If you right-click on the tablespace, you need to select Add Datafile from the resulting menu. In the General tab, enter the information on the new file that you want to add to your tablespace and click Create (if you are using the right-click method) or Apply (if you are just using the click on the tablespace method). Figure 10.6 shows the screen on which you can specify the location of data files that you want to add to a tablespace and the location of the tab on which you can specify the storage parameters connected to the tablespace and its associated data files. Figure 10.7 shows you the options available on the storage parameters tab.

Figure 10.6. OEM Add Datafile screen.

Figure 10.7. OEM Add Datafile storage parameters.

Creating a Tablespace

You can create a tablespace using OEM as well as create tablespaces from the command line.

From a launched OEM console, expand the database that you are going to work on from the Database folder. Expand the storage folder and select the Tablespaces folder from within. Right-click on Tablespaces and from the right mouse menu, select Create.

In the General tab of the property sheet, enter the tablespace name that you are trying to create. In the Datafile region, specify the fully qualified data file or data files that you want to have associated with your new tablespace.

On the Storage tab of the property sheet, enter any relevant storage information that you want to have associated with your new tablespace, and click Create. (Refer to Figure 10.3 to see the tablespace creation screen.)

OEM is the first tool that Oracle provides to help with the administration of tablespaces; Oracle Managed Files (OMF) is the other. The next section looks at OMF and the role it plays in tablespace and data file maintenance.

We have come to the end of the historically standard way of manipulating tablespaces and their associated data files. But with OMF, there are interesting new ways of accomplishing this maintenance and management.


Implementing Oracle Managed Files (OMF)

Oracle 9i has the OMF feature that assists with the management and maintenance of database files.

One new initialization parameter is needed when you are using OMF with tablespaces in the database, DB_CREATE_FILE_DEST. You set this parameter to provide the default location for data files. The parameter, of course, can be overridden in a CREATE TABLESPACE statement. You can either set this parameter directly in the parameter file (init SID.ora), or it can be set dynamically through the use of the ALTER SYSTEM command:

ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/mydatabases/mydb1';

After your database is configured to use OMF, the DATAFILE clause of the CREATE TABLESPACE command is no longer necessary. The data file is created in the file system or directory specified by the DB_CREATE_FILE_DEST parameter in the PFILE or the SPFILE. DB_CREATE_FILE_DEST defines the default file system directory location where Oracle creates data files or tempfiles when no file specification is given in the CREATE TABLESPACE or CREATE TEMPORARY TABLESPACE operation. This location is also used as the default file system directory for online redo log and control files if DB_CREATE_ONLINE_LOG_DEST_n is not specified.

By default, files are 100MB in size unless otherwise specified and also have AUTOEXTEND turned on with unlimited restriction on the data file.

When a tablespace is dropped when you are using OMF, you don't have to specify the AND DATAFILES option; the data files are dropped automatically.

DB_CREATE_ONLINE_LOG_DEST_n should be also set so that you can deliberately control where Oracle puts not only the data files but the online redo log files and the control files as well. Simply setting DB_CREATE_FILE_DEST does not control these other files.

Now that we have established the different kinds of tablespaces and how to create, delete, and maintain your tablespaces, it would be good to know where you can go to find information about the tablespaces in your database.


Data Dictionary Tablespace and Data File Information

Tablespace information can be found in the data dictionary in the views that you can find in Table 10.1. Table 10.1 is a list of data dictionary views along with a brief description of the information that can be found through those views.

Table 10.1. Data Dictionary Views of Tablespace Information

View

Description

V$TABLESPACE

Provides the name and number of tablespaces.

DBA_TABLESPACES

Provides descriptions of all tablespaces.

USER_TABLESPACES

Provides descriptions of all the given user's accessible tablespaces.

DBA_SEGMENTS

Provides information about segments associated with all tablespaces.

USER_SEGMENTS

Provides information about segments owned by the given user's accessible tablespaces.

DBA_EXTENTS

Provides information about data extents associated with all tablespaces.

USER_EXTENTS

Provides information about data extents associated with all tablespaces owned by a given user.

DBA_FREE_SPACE

Provides information about free extents associated with all tablespaces.

USER_FREE_SPACE

Provides information about free extents associated with all the given user's accessible tablespaces.

V$DATAFILE

Provides information about all data files, including the tablespace number of owning tablespace. This can be connected to V$TABLESPACE to get the tablespace data file correlation.

V$TEMPFILE

Provides information about all tempfiles, including tablespace number of owning tablespace.

DBA_DATA_FILES

Provides information on data files belonging to tablespaces.

DBA_TEMP_FILES

Provides information on tempfiles associated with temporary tablespaces.

DBA_USERS

Provides information about the default tablespace and temporary tablespaces for all users.

DBA_TS_QUOTAS

Provides information concerning tablespace quotas for all users.


Exam Prep Questions

1:

You issue the command

ALTER TABLESPACE TEMP ADD DATAFILE '/mydatabases/mydb1/temp02.dbf' 100M;

and you receive the error

ORA-03217: invalid option for alter of TEMPORARY TABLESPACE

What is the problem with the statement?

  • A. You didn't specify any storage specifications.

  • B. You can't add a data file to a temporary tablespace.

  • C. You can't add a data file to a temporary tablespace with the ALTER TABLESPACE command.

  • D. You specified an invalid location for the file.

A1:

Answer C is correct. You must use the ALTER DATABASE command to add a tempfile to the temporary tablespace. Answer A is incorrect because you don't have to specify any storage specifications when you add a data file to an existing tablespace. It takes on the same specifications as the other data files associated with the tablespace. Answer B is incorrect; you can add tempfiles to temporary tablespaces but you have to use the parameter add temp file. Answer D is incorrect; your location is likely correct, and that isn't the error you would get if it was incorrect.

2:

You run the following statement:

CREATE TABLESPACE mydb1data2
DATAFILE '/mydatabases/mydb1/mydb1data2_01.dbf' SIZE 200M
MINIMUM EXTENT 4K
NOLOGGING
DEFAULT STORAGE (INITIAL 10K NEXT 10K)
EXTENT MANAGEMENT DICTIONARY
SEGMENT SPACE MANAGEMENT AUTO;

Why does this statement return an error?

  • A. Segment storage management cannot be set to AUTO for a dictionary managed tablespace.

  • B. You can't define a tablespace as NOLOGGING if it is managed in the data dictionary.

  • C. You can't define a tablespace as dictionary managed in Oracle 9i.

  • D. You can't create a tablespace with a minimum extent of only 4KB.

A2:

Answer A is correct. You cannot set extent management to AUTO for a dictionary managed tablespace. Answer B is incorrect; you can define a tablespace as NOLOGGING regardless of whether it is locally managed or dictionary managed. Answer C is incorrect; not only can you create a dictionary managed tablespace in Oracle 9i, it is still the default if not the recommended method. Answer D is incorrect; you can specify any minimum extent size you want to for a tablespace.

3:

You issue the following query to move your undo tablespace to a more appropriate location:

[View full width]

ALTER TABLESPACE undo01 RENAME DATAFILE '/mydatabases/mydb1/undo01_01.dbf' TO '
  /mydatabases2/mydb1/undo01_01.dbf';

What is the outcome of this command?

  • A. An error because the new data file is the same name as the old data file.

  • B. The data file is moved to the new location.

  • C. An error because the DATAFILE keyword does not need to be specified.

  • D. An error because you cannot rename an undo tablespace's filename with an ALTER TABLESPACE command.

A3:

Answer D is correct. You can only move the undo tablespace's data file with the ALTER DATABASE command when the database is mounted but not open and only if you have copied the data file to the new location with the specified name. Answer A is incorrect; although you cannot move a data file with the ALTER TABLESPACE command, as long as the file exists, it doesn't matter what the name is. Answer B is incorrect because you cannot move an undo tablespace's data file in this manner. Answer C is incorrect; even if it were a "regular" tablespace, you have to use the DATAFILE keyword in the statement.

4:

Which of the flowing is true?

  • A. Segments make up extents, extents make up tablespaces, and tablespaces make up databases.

  • B. Extents make up tablespaces, tablespaces make up segments, and segments make up databases.

  • C. Extents make up segments, segments make up tablespaces, and tablespaces make up databases.

  • D. Databases make up segments, segments make up extents, and extents make up data files.

A4:

Answer C is correct. Extents make up segments, segments make up tablespaces, and tablespaces make up databases. Answers A, B, and D are incorrect.

5:

You have created a new data tablespace as locally managed with auto-matic space management. Where is the free space managed?

  • A. The data dictionary

  • B. The control file

  • C. In the data file

  • D. In the temporary tablespace

A5:

Answer C is correct. The free space is managed and tracked in a bitmap in the data file. Answer A is incorrect; dictionary managed tablespace manages free space in the data dictionary. Answer B is incorrect; free space is never tracked in the control file. Answer D is incorrect; free space for a locally managed data tablespace is never tracked in the temporary tablespace.

6:

You have decided to create your database with Oracle Managed Files. Where are the data files created by default?

  • A. In the location specified by DB_CREATE_ONLINE_LOG_DEST_n

  • B. In the SYSTEM tablespace

  • C. In a user's default temporary tablespace whenever the user creates the tablespace

  • D. In the location specified by the DB_CREATE_FILE_DEST

A6:

Answer D is correct. Data files are created in the location specified by the DB_CREATE_FILE_DEST parameter. Answer A is incorrect; redo logs and control files are created in the location specified by DB_CREATE_ONLINE_LOG_DEST_n. Answer B is incorrect because data files are not created in the SYSTEM tablespace; they are created in the file system of the operating system on which the database is running. Answer C is incorrect; data files are not created in tablespaces, but in the file system.

7:

Evaluate the following SQL command:

CRATE TEMPORARY TABLESPACE mydb1_temp
TEMPFILE '/mydatabases/mydb1/mydb1_temp_01.dbf' SIZE 100M
AUTOEXTEND ON;

Which statements are true about the statement? [choose all that apply]

  • A. Your new temporary tablespace is locally managed.

  • B. Your new temporary tablespace is dictionary managed.

  • C. You can rename the tempfile with the ALTER TABLESPACE command.

  • D. You can rename the tempfile with the ALTER DATABASE command when the database is mounted but not open.

  • E. You can add a tempfile with an ALTER TABLESPACE command.

  • F. You can add a tempfile with an ALTER DATABASE command.

A7:

Answers B, D, and F are correct. Your new temporary tablespace is dictionary managed, it can only have its tempfiles renamed with the ALTER DATABASE command, and the only way to add a tempfile to the temporary tablespace is to alter the database. Answer A is incorrect; unless otherwise specified (and it is not in this case), tablespaces are still created by default as dictionary managed. Answer C is incorrect; you cannot rename tempfiles with the ALTER TABLESPACE command. Answer E is incorrect; you cannot add a tempfile with the ALTER TABLESPACE command.

8:

Which of the following identifies a feature of Oracle 9i that, when implemented, will force all segment extents allocated in a tablespace to be the same size, regardless of storage allocations defined on the objects in the tablespace?

  • A. AUTOEXTEND

  • B. Uniform extent management

  • C. MAXEXTENTS

  • D. Storage

A8:

Answer B is correct; uniform extent management causes all extents in all segments in a tablespace to be the same size regardless of storage parameters provided to any of the individual objects stored in that tablespace. Answer A is incorrect; AUTOEXTEND is concerned with tablespaces and allowing them to grow automatically without intervention from the DBA. Answer C is incorrect; MAXEXTENTS tells Oracle the maximum number of extents that you want to be able to be built in a tablespace or on an object in the tablespace depending on where the parameter is used. Answer D is incorrect, a CREATE TABLESPACE statement has a storage clause, but the word storage itself won't cause the extents to be the same size.

9:

Which are ways that tablespaces can be brought offline? [check all that apply]

  • A. IMMEDIATE

  • B. ABORT

  • C. NORMAL

  • D. trANSACTIONAL

  • E. TEMPORARY

A9:

Answers A, C, and E are all ways that you can bring tablespaces offline. NORMAL will not require media recovery, IMMEDIATE probably will require media recovery, and TEMPORARY won't likely require media recovery if all the data files were online at the time that you took the tablespace offline. Answers B and D are both ways that you can shut down the database but not ways of taking tablespaces offline.

10:

Which tablespace or tablespaces cannot be brought offline as long as the database is open? [select all that apply]

  • A. SYSTEM tablespace

  • B. User data

  • C. User indexes

  • D. Default temporary tablespace

  • E. SYS tablespace

A10:

Answers A and D are correct; you cannot offline the SYSTEM tablespace nor the default temporary tablespace while the database is open. All the other tablespaces can be brought offline, including the SYS tablespace because it is not an Oracle-provided tablespace and would have been user defined.


Need to Know More?

If you want to know more on these topics, you can look in the Oracle9i SQL Reference and Oracle9i Concepts manuals on http://tahiti.oracle.com.


Chapter 11. Managing Undo Data

Terms you'll need to understand:

  • Rollback

  • Undo

  • UNDO_MANAGEMENT

  • UNDO_TABLESPACE

  • UNDO_RETENTION

  • UNDO_SUPPRESS_ERRORS

  • V$UNDOSTAT

  • V$ROLLNAME

  • V$ROLLSTAT

  • V$TRANSACTION

  • V$SESSION

  • DBA_ROLLBACK_SEGS

  • CREATE UNDO TABLESPACE

Concepts you'll need to master:

  • Describe the purpose of undo data.

  • Implement automatic undo management.

  • Create and configure undo segments.

  • Obtain undo segment information from the data dictionary.

Historically, Oracle has used rollback segments to manage space dedicated to providing the ability to undo a transaction. This method (rollback segments) is now referred to as manual undo management mode. Manual undo management mode is still supported under all compatibility levels. You can still use this method when you are migrating to Oracle 9i to take advantage of some features or to be compliant, even if you are not yet ready to convert to automatic undo management mode (the new Oracle 9i method of automatically managing these segments). This chapter explains manual undo management and how it differs from automatic undo management.

The term undo has replaced what was known in previous versions of the database as rollback. This chapter covers automatic undo management and how it happens in the Oracle 9i instance and database.

In manual undo management, you create, allocate, and tune undo segments manually. This was the only option in previous releases of the database.


Logical Structure of Undo Segments in the Database

Undo segments are used to save the old value of a changed data element whenever a process changes any data in the database. It stores the location of the data as well as the value of the data as it existed before it was modified.

The header of an undo segment contains an internal transaction table where the information about the current transaction using the undo segment gets stored. A serial transaction uses a single undo segment in which you can store all the undo information for that transaction, and several concurrent transactions can write to the same undo segment.

Oracle uses undo segments for several purposes. Those purposes are covered in the following section.


Purpose of Undo Data

Undo data serves several purposes in an Oracle database, and none of these purposes is trivial. All are important to the efficient and effective management of your database. It is therefore important to understand the purposes the undo data serves so that we can maintain it effectively.

Transaction Rollback

Whenever a transaction has modified a row in a table, the old image of these modified columns, the columns' undo data, is saved in the undo segment. If the transaction is rolled back for any reason, Oracle restores the original value or values by writing those values back to the row. This operation, and the command to achieve the purpose, is known as rollback (hence the old term for undo).

Transaction Recovery

If an instance fails and transactions are still in progress, Oracle needs to undo any of the uncommitted changes made when the database was open last. This is still rolling back but is now being done not by the users' choice, but as a part of transaction recovery. Recovery of these changes is possible only because all changes made to the undo segments are also protected by the information in the online redo log files.

Read Consistency

While transactions are actively in progress, other users are usually in the database. These users should not be able to see any uncommitted changes made to the data by other transactions. Even if a query starts before another transaction commits, if that query is actively in process when that update transaction commits, the query should not be able to access the newly committed data. This concept is called read consistency, and the old values of the data, the undo data values that are still in the undo segments, are used to provide the users with a consistent image for any given statement.

Oracle guarantees that every statement will see its data from a consistent time, even if any or all of that data is modified, or in the process of modification, by other transactions.

Whenever the Oracle server begins to execute a user's SELECT statement, it determines the system's current System Change Number (SCN) and ensures that any changes committed before this SCN are processed by the SELECT. Any changes that have not been committed before this SCN are not accessible to the SELECT statement.

For example, you have a long-running query that you are executing. You start this query at 11:00 a.m., when several other users are on the system, each with his own transactions, some updating, some inserting new data, some deleting, others running queries. Several row changes have already been committed when you start your SELECT statement. Others have not yet either been committed or rolled back. If a row has changes to it that were not committed at the beginning of your query, there is no way to determine whether they will be committed or rolled back. If a row that has uncommitted changes is a member of the resultset of your query, Oracle constructs a read-consistent image of that entire row by retrieving the before image of all changes from the undo segments and applying those changes to a copy of the row in memory.

Transaction Read Consistency

Read consistency is always provided by Oracle for the duration of any given SQL statement; however, you can request read consistency for the duration of an entire read-only transaction (or series of SQL statements) by issuing the following command:

SET TRANSACTION READ ONLY;

If you have a transaction that will be performing Data Manipulation Language (DML) operations, you can also request read consistency be maintained for the duration of that entire transaction. This is accomplished by issuing the following at the beginning of the transaction:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

In both cases, Oracle provides the data for the entire transaction, start to finish, and a read-consistent image of all of the data involved in the transaction.

It is important to remember that using SERIALIZABLE can have negative impacts on performance.


Types of Undo Data

There are three types of undo segments. The first two are similar to the two types of tablespacesSYSTEM and non-SYSTEMand the third is called deferred.

SYSTEM

SYSTEM undo segments are used for objects in the SYSTEM tablespace. The SYSTEM undo segment is created in the SYSTEM tablespace whenever a database is created and works the same regardless of whether the maintenance mode is manual or automatic.

Non-SYSTEM

Non-SYSTEM undo segments are used for all objects in any tablespace other than the SYSTEM tablespace. These segments can either be created with automatic undo management or manual undo management. The two different ways that segments can be managed are detailed as follows:

  • Manual undo management In manual undo management mode, a non-SYSTEM undo segment created deliberately by the database administrator can be utilized to maintain undo information on non-SYSTEM objects located in tablespaces. Private undo segments are those brought online by an instance because they are listed in a parameter file or because a DBA has issued an ALTER ROLLBACK SEGMENT command. Public manual undo segments form a pool of undo segments that then become available to the database. They are normally used with Oracle Parallel Server to create a pool of undo segments that can be used by any of the Parallel Server instances. You must create at least one non-SYSTEM undo segment before you can create anything in the database, including additional tablespaces. This DBA-created, non-SYSTEM undo segment is created in the SYSTEM tablespace and should be taken offline and dropped after you have created your undo tablespace and segments.

  • Automatic undo management In automatic undo management, undo data is managed using the undo tablespace. You, as DBA, allocate one active undo tablespace per instance, allocated with sufficient space for the workload of the instance. With this undo tablespace, Oracle automatically maintains the undo data. The undo segments are created in the database with the naming convention _SYSSMUn$ (for example, _SYSSMU1$, SYSSMU2$, and _SYSSMU3$).

Deferred

Deferred is used whenever tablespaces are taken OFFLINE IMMEDIATE, OFFLINE TEMPORARY, or OFFLINE FOR RECOVERY, and transactions are accessing the data in these tablespaces. They are used to facilitate the rolling back of transactions when the tablespace is brought back online and are dropped automatically when they are no longer needed. Because they are created and maintained by Oracle, no maintenance is required on the part of the DBA, but the knowledge that they exist and their purpose is important.

Oracle suggests that automatic undo management is the preferred method in Oracle 9i. In the next section, we discuss how to configure your instance and database to use automatic undo management.


Implementing Automatic Undo Management

Configuration of your database and its instance to use automatic undo management requires the addition of two parameters in the initialization file: UNDO_MANAGMENT and UNDO_TABLESPACE.

  • UNDO_MANAGEMENT tells the system whether it should use the automatic (determined by setting this parameter to AUTO) method of undo management or the manual (determined by setting this parameter to MANUAL) method. UNDO_MANAGEMENT cannot be reset dynamically after the database starts. AUTO starts the database in the automatic undo method and requires that you have at least one undo tablespace created in the database in which it can manage its undo segments. If you choose to run your instance in MANUAL mode, which is still the default mode, you can create and manage the undo segments whenever needed by the database just as in previous versions of Oracle.

  • UNDO_TABLESPACE specifies to Oracle which undo tablespace is to be used for the management of undo segments in the database. This parameter can be set in the initialization file or can be set, and reset, dynamically using the ALTER SYSTEM command as follows:

    ALTER SYSTEM SET UNDO_TABLESPACE = mydb1_undo1;

In addition, you have to create at least one undo tablespace in the database. If you have only created one undo tablespace in the database and your UNDO_MANAGEMENT parameter is set to AUTO, the UNDO_TABLESPACE parameter is optionally set and will default to the single UNDO_TABLESPACE that is configured.

You will recall that, when we created the database earlier, we created it with an undo tablespace mydb1_undo1 in the following manner:

CREATE DATABASE mydb1 CONTROLFILE REUSE
LOGFILE
GROUP 1 ('/mydatabases/mydb1/log01a.log', '/myotherdatabase/mydb1/log01b.log') SIZE 50M,
GROUP 2 ('/mydatabases/mydb1/log02a.log', '/myotherdatabase/mydb1/log02b.log') SIZE 50M,
GROUP 3 ('/mydatabases/mydb1/log03a.log', '/myotherdatabase/mydb1/log03b.log') SIZE 50M,
GROUP 4 ('/mydatabases/mydb1/log04a.log', '/myotherdatabase/mydb1/log04b.log') SIZE 50M
DATAFILE '/mydatabase/mydb1/mydb1_system.dbf' 250M
UNDO TABLESPACE mydb1_undo1
DATAFILE '/mydatabase/mydb1/mydb1_undo1.dbf' 50M
DEFAULT TEMPORARY TABLESPACE mydb1temp tempfile '/mydatabases/mydb1/mydb1temp1.dbf' size 75M
EXTENT MANAGEMENT LOCAL;

During database creation, if you have set UNDO_MANAGEMENT to AUTO and have omitted the creation of the undo tablespace, Oracle creates an undo tablespace for you called SYS_UNDOTBS with the default data file located in the $ORACLE_HOME/dbs directory. The data file will be named dbu1<SID>.dbf and will have an operating system dependent size and AUTOEXTEND set to ON.

You can also create the undo tablespace after database creation with the following CREATE UNDO TABLESPACE command:

CREATE UNDO TABLESPACE mydb1_undo1
DATAFILE '/mydatabase/mydb1/mydb1_undo1.dbf' 50M;

Notice that the CREATE TABLESPACE command for the undo tablespace requires the UNDO keyword. This tells Oracle that this tablespace needs to be created specially for the expressed purpose of maintaining undo information.

Altering the Undo Tablespace

Altering an undo tablespace is the same as altering any other tablespace, you simply make the alterations in the ALTER TABLESPACE command, including adding data files, resizing data files and in effect the tablespace, onlining and offlining the data file, beginning and ending backups, and anything else that you can do with a tablespace.

Switching Undo Tablespaces

You can freely switch from using one undo tablespace to using another. Although only one undo tablespace can be active in a database at any one time, you can make different ones active whenever you see the need do so. Because more than one undo tablespace can exist in a database at any one time, with only one active, this is much easier to do on-the-fly. You can simply switch between undo tablespaces with the ALTER SYSTEM command that follows:

ALTER SYSTEM SET UNDO_TABLESPACE=mydb1_undo2;

Although this command will take effect immediately, it is important to note that the "old" undo tablespace may remain active for a period, because active transactions won't be switched to the new tablespace. As new sessions connect and new transactions start, those transactions will be started in the new tablespace.

Dropping an Undo Tablespace

Simply, the DROP TABLESPACE command drops an undo tablespace as elegantly as it drops any other tablespace. An undo tablespace can be dropped only if no active transactions are using the tablespace for maintenance of its undo segments. If the undo tablespace that you need to drop is the active undo tablespace, you first need to make another undo tablespace the active undo tablespace and then drop the tablespace after all active transactions that were using it have completed. The following query can help you to determine when all transactions have stopped using this undo tablespace:

SELECT a.name,b.status
FROM v$rollname a, v$rollstat b
WHERE a.name IN ( SELECT segment_name
FROM dba_segments
WHERE tablespace_name = 'MYDB1_UNDO1')
AND a.usn = b.usn;

Whenever this query returns with no rows found, you can safely stop the undo tablespace in question.

Oracle may still have references to an old undo tablespace even after it has been switched to a new one for the purpose of read consistency. Queries that require information from the switched or dropped undo tablespace after it is no longer available will receive the error: ORA-1555 snapshot too old.

Automatic Undo Management Parameters

Several other parameters for the initialization files control different aspects of automatic undo retention.

UNDO_SUPPRESS_ERRORS

UNDO_SUPPRESS_ERRORS enables users to suppress errors that they may encounter while executing manual undo management mode operations while in automatic undo management mode. An example of an operation that would cause errors to be generated is ALTER ROLLBACK SEGMENT ONLINE (or OFFLINE). These commands are already often embedded in programs, and the switch from manual to automatic undo management mode would ordinarily cause these commands to fail and the program from where they are called to likely fail as well. Setting this parameter enables the use of the automatic undo segment management before all the programs and scripts have been converted completely to remove references to these manual mode commands.

If this parameter is unset, the program would cause the following ORA-30019 error:

ORA-30019: Illegal rollback segment operation in the automatic undo mode.

UNDO_RETENTION

The UNDO_RETENTION parameter determines how long to retain undo data to provide for consistent reads in the database. The retention of undo data longer allows for longer queries to run when active updates are occurring in the database. It also means that larger files need to be allocated for the undo tablespace. The UNDO_RETENTION parameter is defined in seconds and can be set either in the initialization file or modified dynamically with the ALTER SYSTEM command. To dynamically set the undo retention period to 20 minutes, you would execute the following ALTER SYSTEM command:

ALTER SYSTEM SET UNDO_RETENTION=1200;

Even if you have the UNDO_RETENTION parameter set, if the undo tablespace is sized too small, undo data will not be retained for the specified period of time. Oracle uses a space allocation algorithm within the undo tablespace to allocate space that has information that has not yet passed the time allotted by UNDO RETENTION but that has no active transactions before it allows a transaction to fail. But this does not preclude the failure if not enough space is available. This may be particularly true in an extremely active database.

Sizing the Undo Tablespace

To appropriately determine the size for an undo tablespace, you need three pieces of information:

  • You need to determine how long you need to maintain undo information in your instance. This is UNDO_RETENTION (UR) in seconds.

  • You need the number of undo data blocks generated per second (UPS) at a peak time in your database. This information can be gotten by querying the V$UNDOSTAT view to determine how many blocks are used in given 10-minute intervals and dividing:

    SELECT end_time, begin_time, undo FROM v$undostat;

    If you determine that you want to maintain undo information for 30 minutes, find the three highest consecutive time periods, or just the highest three time periods, and that will give you the blocks used in 30 minutes. Add up these blocks and divide by 1,500 to get the blocks per second.

    You can also use the following command to determine the number of undo blocks generated per second by running the following query:

    SELECT (SUM(undoblks)/SUM((end_time  begin_time) * 86400))
FROM v$undostat;

    Because whenever you subtract date data types, even if they only span 10 minutes, you are returned the value in days. You need to multiple by the number of seconds in a day to get the number of seconds elapsed in that time period.

  • You will need to determine the db_block_size (DBS).

When you have all three pieces of information, you can mathematically determine how much undo space to allocate for the database by the following formula:

Undospace = [UR * UPS * DBS] + DBS * 24

Or, to generate that information directly from the database, you could run the following query:

SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes"
FROM (SELECT value AS UR
FROM v$parameter
WHERE name = 'undo_retention'),
(SELECT (SUM(undoblks)/SUM(((end_time - begin_time)*86400))) AS UPS
FROM v$undostat),
(SELECT value AS DBS
FROM v$parameter
WHERE name = 'db_block_size');

If you are returned the value 20971520 (as the number of bytes), you will need to divide this number by 1,048,576, the number of bytes in a megabyte, to get the number of megabytes of undo space you need to allocate.

Although you can quantitatively determine how much undo space you will need for the given database under the current load, it would be wise to add a 10% or 15% fudge factor for growth and additional user requirements.

Now that you have allocated the undo space to your database, it still needs to be managed judiciously.

To make the best use of the undo space allocated to a database, you can make decisions concerning space and its allocation. This next section addresses these decisions.

Undo Quota

Long and improperly written transactions can consume more than necessary resources in their executions. Using resource plans, users can be grouped together, and limits can be placed on the amount of resources (undo and others) that can be used by that group. The amount of undo data that can be generated by a given group can be limited by the use of UNDO_POOL and setting its value to some number. By default, this value is unlimited.

Whenever a group, or anyone in that group, exceeds its limits, an error is generated, and no new transactions can be performed until the current transaction either completes or aborts.

Users receive the following error message if their group exceeds its quota:

ORA-30027: Undo quota violation, failed to get <number> bytes.

Advice on this error explains to the user that the amount of undo space assigned to the group of the given session has been exceeded. They are instructed to either ask the DBA to increase the quota or wait until other transactions commit before proceeding.

Now that we have created the undo tablespaces and determined how to limit allocation of segments to a given individual or to a group, we now need to determine where to find information in the data dictionary on undo segments.


Data Dictionary Information on Undo

The means by which to locate undo segment information in the data dictionary is discussed in this section.

  • V$UNDOSTAT Provides statistics on undo data. You can use this view to determine how well the system is working. Each row in the view provides statistics collected in the instance at 10 minute intervals. You can use this view to help to determine how much undo space to estimate for your current workload. The database uses this view somewhat differently; it uses the view to tune undo usage in the system. The view is available for both automatic and manual undo management mode.

    The most recent row in the dynamic view returns the time since the interval started, which is typically less than 10 minutes.

  • V$ROLLNAME Provides the names of all the online undo segments in the database.

  • V$ROLLSTAT Provides statistics on all the online undo segments in the database. It can be joined to v$rollname with the USN column.

  • V$SESSION Lists all the active sessions in the database.

  • V$trANSACTION Lists all the active transactions in the database. If you want to check the use of an undo segment by a currently active transaction, you would join the v$transaction view to the v$session view on V$SESSION.saddr and V$trANSACTION.ses_addr to get the values of XIDUSN, UBAFIL, UBABLK, and USED_UBLK, or how many blocks that transaction is using in the undo tablespace.

    For example:

    SELECT b.username, a.xidusn,
a.ubafil, a.ubablk, a.userd_ublk
FROM V$TRANSACTION a, V$SESSION b
WHERE a.ses_addr = b.saddr;

  • DBA_ROLLBACK_SEGS Provides information about all the undo segments in the database. This is the only place where you can obtain information about undo segments currently offline. The OWNER column specifies the type of undo segment in question. SYS refers to private undo segments; PUBLIC refers to a public undo segment.


Exam Prep Questions

1:

You have two undo tablespaces defined for your database, undo01 and undo02. The instance is currently using undo01. You issue this command to switch to undo02 while transactions are still active in the database:

ALTER SYSTEM SET UNDO_TABLESPACE = undo02

Which result occurs?

  • A. New transactions will be assigned to the undo02 tablespace.

  • B. Current transactions are switched to the undo02 tablespace.

  • C. The switch to undo02 fails, and an error message is returned because transactions are using undo01.

  • D. The switch to undo02 does not take place until all transactions in undo01 are completed.

A1:

Answer A is correct; new transactions will be assigned to the undo02 undo tablespace. Answer B is incorrect; current transactions will continue to use undo01. Answer C is incorrect; the switch of the undo tablespace will complete without error. Answer D is incorrect; the switch will be immediate, and new transactions will use the new undo tablespace.

2:

What structure does Oracle provide to ensure read consistency in the database?

  • A. Redo log files

  • B. Control files

  • C. Data dictionary

  • D. Data files

  • E. Undo segments

A2:

Answer E is correct. Undo segments provide read consistency for queries. Answer A is incorrect; redo log files provide a mechanism to store data changes before they are written to disk. Answer B is incorrect; control files record changes to the database's structure. Answer C is incorrect; the data dictionary stores the system's objects. Answer D is incorrect; data files store the database's data.

3:

You set UNDO_RETENTION to 500 seconds. What is one possible reason that you may not have 500 seconds worth of undo information in the undo tablespace?

  • A. 500 seconds is an invalid value for UNDO_RETENTION.

  • B. Your undo tablespace is too small to hold that much undo information.

  • C. Your system is extremely quiet that day, and the users aren't generating 500 seconds worth of undo information.

  • D. The rollback segments are full.

A3:

Answer B is correct; your undo tablespace is likely too small to hold 500 seconds worth of undo information. Answer A is incorrect; 500 seconds is a valid setting for UNDO_RETENTION. Answer C is incorrect; 500 seconds doesn't depend on any transactions taking place. In fact, fewer transactions means your retention is even longer than required. Answer D is incorrect; with automatic undo you don't have rollback segments.

4:

You have one undo tablespace in your database. You try to take the undo tablespace offline. What is the effect of this action?

  • A. The undo tablespace is offlined.

  • B. The undo tablespace is put into pending offline mode.

  • C. The database reverts to manual undo retention.

  • D. You receive an error because you cannot offline the only undo tablespace in the database.

A4:

Answer D is correct, you cannot offline the only undo tablespace in the database, and an attempt to do so causes an error. Answers A and B are incorrect; you cannot offline the only undo tablespace in a database. Answer C is incorrect. You can only deliberately revert back to manual undo management mode; the database won't do it for you.

5:

Your database is running in automatic undo management mode and you are trying to determine whether you need to resize your undo tablespace. You have queried the V$ROLLSTAT view to find out how many blocks of undo are generated on average in your database. Will this method provide the information that you need?

  • A. Yes, in the extents column.

  • B. No, V$ROLLSTAT does not provide you with the blocks used in automatic undo management mode.

  • C. Yes, but only averaged at every 10 minutes.

  • D. Yes, but you will have to multiply to determine the number of megabytes because the information is stored in blocks.

A5:

Answer B is correct; V$UNDOSTAT provides the desired information when you are running in automatic undo management mode. Answer A is incorrect; the extents column tells you the number of extents in the rollback segments for manual undo managed rollback. Answer C is incorrect; however, V$UNDOSTAT provides the information required at 10-minute intervals, which will not meet your requirements, but may meet others. Answer D is incorrect because the information is not available in any way from V$ROLLSTAT.

6:

You have set UNDO_RETENTION for 900 seconds. Your users have started to complain about getting snapshot too old errors. What can you infer about your undo tablespace from this?

  • A. That your undo tablespace is too large, and you have too much undo information available.

  • B. That your undo tablespace must be offline, and users are seeing the results.

  • C. That your undo tablespace is too small to maintain enough undo information to provide read-consistent information.

  • D. Your undo tablespace is fine, but your users are using the SYSTEM rollback segment.

A6:

Answer C is correct; you can infer that your tablespace is too small to provide sufficient space for the undo. Answer A is incorrect because a too large tablespace will only provide extra room to maintain more undo information. Answer B is incorrect; you will not get snapshot too old errors just because your undo tablespace is offline. If it is the only undo tablespace, it can't be offline. Answer D is incorrect; if there is an undo tablespace and you are using automatic undo, you will not be using the SYSTEM rollback segment.

7:

Your UNDO_SUPPRESS_ERRORS parameter is set to TRUE. What are the ramifications to your applications because of this setting?

  • A. Your applications won't be able to suppress errors any more.

  • B. Your application won't generate errors any more.

  • C. You will get errors connected to automatic undo segments.

  • D. You won't get errors if your application attempts to online or offline rollback segments.

A7:

Answer D is correct; errors connected to use of manual undo will be suppressed if you are using automatic undo management and manual undo commands. Answer A is incorrect; your application will suppress manual undo command errors. Answer B is incorrect; your application will generate application errors but not manual undo errors. Answer C is incorrect; you are running automatic undo management, and you will get automatic undo errors if they are generated.

8:

If you need to retain undo information for 20 minutes, to what do you need to set UNDO_RETENTION?

  • A. 1200

  • B. 20

  • C. The average number of undo blocks per second times 60 seconds times 20 minutes

  • D. 500 megabytes

A8:

Answer A is correct; you need to set the UNDO_RETENTION parameter to 1200 for 1200 seconds. Answer B is incorrect; UNDO_RETENTION is in seconds, not in minutes. Answer C is incorrect; there is no math needed past the number of minutes * 60 seconds. Answer D is incorrect; UNDO_RETENTION is in seconds not in megabytes.

9:

What is the effect of the following statement on an instance using an SPFILE?

ALTER SYSTEM SET UNDO_MANAGEMENT AUTO;

  • A. The system will immediately be in automatic undo management mode.

  • B. The system will be in automatic undo management mode after you define an undo tablespace.

  • C. You will be in automatic undo management mode after you restart the instance.

  • D. Nothing, all databases run in automatic undo mode in Oracle 9i.

A9:

Answer C is correct; you need to restart the database to change undo management mode. Answer A is incorrect; UNDO_MANAGEMENT is not a dynamic parameter. Answer B is incorrect; you do have to have an undo tablespace defined, but you still need to restart the database. Answer D is incorrect; manual undo is still the default method in Oracle 9i. Automatic undo is the suggested method.

10:

What is not a purpose of undo segments? [select all that apply]

  • A. To enable transaction rollback

  • B. To enable read consistency

  • C. To enable transaction read consistency

  • D. To enable instance recovery

A10:

Answer D is correct. The only answer that is not a purpose of undo segments is to enable instance recoverythat is, redo log files. Answers A, B, and C are all purposes of undo segments.


Chapter 12. Managing Tables

Terms you'll need to understand:

  • External tables

  • Partitioned tables

  • Cluster tables

  • Regular tables

  • Index-organized tables

  • Truncate

  • ALTER TABLE

  • Scalar data types

  • User-defined data types

  • LOBs

  • ROWID

Concepts you'll need to master:

  • Identify the various methods of storing data.

  • Identify Oracle data types.

  • Distinguish between extended and restricted ROWID.

  • Identify the structure of a row.

  • Create regular and temporary tables.

  • Manage the storage structures within a table.

  • Reorganize, truncate, and drop tables.

  • Drop columns within a table.

  • Rename a column within a table.

  • Move tables from one tablespace to another.

As a database administrator, you will likely spend a considerable amount of time managing tables or managing objects surrounding tables. This chapter provides an overview of the different kinds of tables you will encounter both on your exam and in your Oracle 9i DBA career.

Tables are the way that Oracle, and other relational databases, store data. This means that tables are a key component of the database and one of the most important to your users, and by extension tables will be very important to you. No tables, no data; no data, no need for a DBA.


Methods of Storing Data

There are several different methods of storing data in tables in the database. These methods are covered in this section. From the user's perspective, however, all appear the same, and all the different storage options provide the same functionality. From the user's perspective, SELECT, INSERT, UPDATE, or DELETE all appear to function in the same way.

Regular Tables

A regular table, or more commonly just a table, is the most commonly used method of storing user data in a typical Oracle database. It is the default method used and is also the main focus for this chapter. Database administrators have little control over how the rows are distributed in a regular table, and users have even less. Rows are stored randomly in the table, depending on the activity on the table.

Partitioned Tables

Partitioned tables have one or more partitions, each of which stores rows that have been placed into a particular partition based on the partitioning criteria specified. This is accomplished either by range partitioning, hash partitioning, composite partitioning, or list partitioning. Each partition is a segment, and each can be located in either the same tablespace or a different tablespace from the others.

Range Partitioning

Range partitioning maps data to the appropriate individual partitions based on ranges of partition key values (the values for the column on which you are going to base the partitioning) that you establish for each partition. Range is the most common type of partitioning used, and it is often used when partitioning by date range. For example, you might want to partition claim data by month into a monthly partitioning scheme or by year, each year into its own partition.

When deciding whether to use range partitioning, consider the following general rules:

  • Each partition has a VALUES LESS THAN clause. This clause specifies the noninclusive upper bound for the partitions. Any values for the partitioned column that are less than the clause specified value are directed into one partition. Those that are equal to or higher than this literal value are added to the next higher partition.

  • All partitions, except the first and lowest partition, have an implicit lower bound specified by the VALUES LESS THAN clause on the next lower partition.

  • A MAXVALUE literal, which represents a virtual infinite value that will always sort higher than any other possible non-null value, can be defined for the highest partition.

Hash Partitioning

Hash partitioning is the method that enables the easy partitioning of data that does not lend itself to range or list partitioning. Either because of the distribution or the type of data involved, it just doesn't seem to fit with the other partitioning concepts. This partitioning is accomplished with simple syntax that is also easy to implement. Hash partitioning is a better choice than range partitioning under the following conditions:

  • You do not know beforehand how much data will end up mapping into a given range.

  • The sizes of the resulting range partitions would differ substantially from each other or would be difficult to balance manually. This would mean that queries retrieving data from one partition (a larger partition) would likely run longer than those against another, smaller partition.

List Partitioning

List partitioning, new in Oracle 9i, enables you to explicitly control how rows map to partitions. You accomplish this controlled mapping by specifying a customized list of discrete values for values of the partitioning key. This is different from range partitioning, where a range of values is defined for a partition, and from hash partitioning, where a hash function controls the row-to-partition mapping. The primary advantage of list partitioning is that you can group and organize unordered and apparently unrelated sets of data in a more intuitive and natural way.

This means that you can group data by locationfor example, all Eastern European data in one partition and all Western European data in another partitionor group state-related data by area of the United States. This would be particularly effective if queries on the data were typically concerned with finding answers by regions (all sales for the Midwest could be found in one partition; all claims for workers in London would be in their own partition).

Composite Partitioning

Composite partitioning partitions data first using the range method. This level of partitioning places the data within its primary partition. Within each partition, the data is further subpartitioned using either the hash or list method.

Composite range-hash partitioning provides the improved manageability of range partitioning along with the more well distributed data placement (fewer hotspots for data) advantages of hash partitioning.

Composite range-list partitioning provides the manageability of range partitioning along with the finer grain, more explicit control of list partitioning for the subpartitions.

Partitioning is particularly useful for large tables that can be queried or have their data manipulated using several different processes concurrently. Special commands are used for the maintenance and manipulation of partitioned tables.

Index-Organized Tables

An index-organized table is similar to a regular table that has a primary key on one or more of its columns; however, instead of maintaining both the table and the index as two different and separate storage spaces, an index-organized table maintains a single B-tree containing both the primary key of the table and the other associated column values. Overflow segments may exist that are associated with index-organized tables due to the PCTTHRESHOLD value being set. The results of longer row lengths requiring overflow are to hold extra values.

Storage requirements are reduced for index-organized tables because the values for the key columns don't have to be duplicated in both the table and the index. The other values in the row are also stored in the index unless the entry becomes very large. If this is the case, Oracle provides an OVERFLOW clause to handle the situation.

Cluster Tables

Cluster tables provide optional methods for storing table data. Clusters (in relationship to tables) are made up of a table, or a group of tables, that share the same data blocks. They are grouped in this manner because they share common columns and often have their data queried or manipulated at the same time.

Clusters have what is known as a cluster key, which is used to identify the rows that need to be stored together. The cluster key can be one column or multiple columns. All tables that participate in the cluster have columns that correspond to the column key.

Clustering, like index-organizing and partitioning, is a mechanism completely transparent to the users and applications using the tables. Data within the cluster's participating tables can be manipulated just as it could in any other table; however, updating one of the columns in the cluster key (not to be confused with the primary key) may entail the physical relocation of the row. Because the cluster key is independent of the primary key, each table that participates in a cluster can have its own primary key, which is, or can be, a different set of columns than those in the cluster key.

Clusters are usually implemented as a means of speeding up data access to improve performance. However, although random access to clustered data may be faster, full table scans on clustered tables are usually slower.

Finally, clusters can renormalize the physical storage of tables without actually affecting the logical structure associated with those tables.

Clusters, index-organized tables, and partitioned tables are covered in greater detail for the Fundamentals II exam, but are covered here to provide you with an understanding that they exist and of their basic properties. Although these advanced topics are dealt with in great detail in later exams, basic questions are possible on the exam dealing with what they are.

Tables are the means by which Oracle stores data. It is therefore important to look at the different types of data that can be found in an Oracle database.


Oracle Data Types

Two general types of data are found in the Oracle database: built-in data types and user-defined data types. This section provides an explanation of both types and the kinds of data associated with each.

User-Defined Data Types

Oracle supports the ability for users to define their own abstract data types and use them within the application. For example, you could define an address type as including street_address1, street_address2, city, state, country, and zip_code and use that type in tables as a single entity rather than as each individual piece. If you always reference addresses in the same way, this can ease coding and facilitate reuse.

Built-In Data Types

Oracle provides several built-in data types to store scalar data, collections, and relationships.

Scalar Data

Scalar data is data that can take on a single value, even if that value is large. The following list describes in more detail the various scalar types available in Oracle:

  • CHAR(N) Represents character data that is a fixed length of N bytes. If the data stored in the CHAR field does not take up the entire N bytes, the data gets padded with blanks. The minimum size of a CHAR column is 1 byte. The maximum is 2000 bytes. Character, or CHAR, data can be any string of charactersalpha, numeric, or special characters.

  • NCHAR(N) Represents character data that is a fixed length of N positions and designed to support globalization data. If the data stored in the CHAR field does not take up the entire N bytes, the data gets padded with blanks. The minimum number of bytes or characters (for multibyte characters) is one character. The maximum number of bytes, regardless of the number of bytes per character, is 2000 bytes. More can be found in Chapter 7, "Globalization Support."

  • VARCHAR2(N) A data type that can store variable length data, up to the number of bytes specified by N. This data type uses only the exact number of bytes required to store the exact column value with no additional padding. The maximum number of bytes per column is 4000.

  • NVARCHAR2(N) The globalization version of the VARCHAR2 data type and is a data type that can store variable length data, up to the number of bytes specified by N. This data type uses only the exact number of bytes required to store the exact column value with no additional padding. The maximum number of bytes per column is 4000.

  • NUMBER(P,S) Numeric data in Oracle is always stored as variable length data. Number data types can store up to 38 significant digits that can be split into whole numbers and decimals. Numeric data requires one byte for the exponent, one byte for every two significant digits of the decimal portion of the number, and one byte for negative numbers, if the number of significant digits is less than 38 total bytes.

    The decimal portion of a number is called the mantissa.

  • DATE Stored in a fixed-length field of 7 bytes. DATE type always includes time in hours, minutes, and seconds, even when time is not displayed.

  • TIMESTAMP Stores the date and time, including fractional seconds up to 9 decimal positions. TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE both use time zones to factor items such as Daylight Savings Time in the United States. A column defined as TIMESTAMP and a column defined as TIMESTAMP WITH LOCAL TIME ZONE can be candidate keys for the primary key of a table. TIMESTAMP WITH TIME ZONE cannot.

    With TIMESTAMP WITH TIME ZONE you can store the offset or time zone displacement. The displacement is the amount of time difference, in hours and minutes, between the local time and the Universal Time Coordinated (UTC), which was formally know as Greenwich Meridian Time (GMT). TIMESTAMP WITH TIME ZONE represents absolute time. This feature takes up extra bytes of storage.

    With TIMESTAMP WITH LOCAL TIME ZONE you can store the standardized time zone information much as you can with TIMESTAMP WITH TIME ZONE; however, instead of storing the offset as additional bytes of storage, the time values are normalized and stored in terms of the database's time zone. Whenever a user attempts to retrieve the normalized information, the database displays the information in terms of the user's local time.

    TIMESTAMP WITH TIME ZONE requires extra storage bytes for every column with that data type; TIMESTAMP WITH LOCAL TIME ZONE does not.

  • RAW(N) Enables you to store small binary data without Oracle performing character set conversions whenever the RAW data is transmitted either across machines or from one database to another using Oracle utilities. A RAW column can be up to 2000 bytes in size.

  • BLOB (Binary Large Objects or BLOBs) Provided by Oracle for storing unstructured data. Supports object type attributes. If the total size of the BLOB is greater than 4000 bytes, Oracle stores a locator in the table and stores the binary data elsewhere (separate segments or tablespaces). BLOBs are considered to actually be raw data because its structure isn't recognized by the database. They are often images, movie clips, or sound bytes.

  • CLOB (Character Large Objects or CLOBs) Large fixed-width character data. Supports object type attributes. If the total size of the CLOB is greater than 4000 bytes, Oracle stores a locator in the table and stores the character data elsewhere (separate segments or tablespaces). A CLOB may be indexed and can be searched by the Oracle Text search engine.

  • NCLOB The data type used for large fixed-width national character set data. If the total size of the NCLOB is greater than 4000 bytes, Oracle stores a locator in the table and stores the character data elsewhere (separate segments or tablespaces).

  • BFILE s Used for storing unstructured data, referenced by the database yet actually stored in operating system files.

  • LONG and LONG RAW For large fixed-width character data; used to be used for unstructured data such as images, documents, and sound bytes. These are no longer the preferred way and are provided now for backward compatibility. Rather than using these data types, it is preferred that you use the LOB data (CLOB, BLOB, NCLOB, or BFILE). LOBs are distinct from LONG and LONG RAW, are not simply interchangeable terminology, and will not support the same application programming interfaces (APIs).

    Some differences between LONG and LONG RAW and the LOB data types are notable. LONG and LONG RAW were limited to one column per table, whereas LOB data can be included in multiple columns per table. LONG and LONG RAW could hold up to 2 gigabytes of data, LOBs can hold up to 4 gigabytes. With LONG and LONG RAW, data was always stored inline; however, with LOBs, it is stored either inline or out of line. LOBs support object types; LONG and LONG RAW don't. LONG and LONG RAW were limited to sequential access to the chunk of data stored in the column; LOBs support random access to the chunks.

    LONGs and LONG RAWs are stored as chained rows with pieces stored in different blocks, each block pointing to the next. There is no random access possible, nor any filelike interface through which to interact with the data.

  • ROWID A unique identifier for each row in the database that is not stored explicitly as a column value but that can be queried (as implicitly included with the table) along with other columns in the table. Although it does not directly provide the physical address of a row, it can be used to locate the row and provides the fastest means for accessing a row in a table. ROWID is stored in indexes to specify rows with a given set of key values.

    The ROWID column is considered to be a pseudo column (not evident when describing the structure of a table or by executing a SELECT * from the table, nor does the ROWID column take up space in the table). You cannot insert, update, or delete the value of ROWID. You can, however, retrieve the value stored in the column by running the following command:

    SELECT ROWID FROM mytable;

    Physical ROWIDs store the addresses of rows in regular tables (not index-organized tables), cluster tables, and table partitions and subpartitions. They also store the addresses of indexes and index partitions and subpartitions. Physical ROWIDs provide the fastest possible access to any row of a given table because they contain the physical address of the row (as far down as the specific block in which it is located), and Oracle guarantees that, as long as the row exists, its physical ROWID does not change with the exception of across import/export operations. The format for these ROWIDs will be covered later in this chapter.

    Logical ROWIDs store the addresses of rows in index-organized tables. Because rows in index-organized tables do not exactly have a permanent physical address (rather they are stored in the index leaves and can therefore move within the block or to different blocks due to insertions), their ROWIDs cannot reference physical addresses. Instead, Oracle provides index-organized tables with logical row identifiers (logical ROWIDs) based on the table's primary key. Oracle then constructs secondary indexes on the index-organized tables based on the logical ROWIDs.

  • UROWID Starting in 8i, Oracle provided a data type called universal ROWID or UROWID. UROWID supports ROWIDs of non-Oracle tables and can store all kinds of ROWIDs (both physical and logical). A UROWID is required if you want to store a ROWID for rows stored in index-organized tables, and the COMPATIBLE setting in the initialization file needs to be 8.1 or higher to use UROWID.

Collection Data

Two types of collection data are available in which to store data that is representative of a given row in a given table. In releases prior to Oracle 8i, the Objects option was required to define and use collections. This is no longer the case.

Varying Arrays

Varying arrays (VARRAY) are useful structures in which to store lists that contain a small number of elements (for example, colors for a sweater or phone numbers for a given client). A VARRAY is an ordered set of data elements that for each VARRAY are the same data type. Each element has an index like any other array, which is a number corresponding to the position of the element in the array. The number of elements in the VARRAY determines its size, and Oracle allows them to be of variable size (thus the VARRAY name). However, the maximum size must be specified when declaring the array type.

Nested Tables

Nested tables provide a means of defining entire tables as a column within a table. They can be used to store sets that may have many records (such as items in an order or a bill of materials for an item). Nested tables are unordered sets or records, and the rows in a nested table all have the same structure. The rows in a nested table are stored separately from the parent table, and a pointer from the parent table row points to the corresponding nested table rows. There is no predetermined size for a nested table, unlike VARRAYS, and the storage characteristics for the nested table are assigned and defined by the database administrator.

Relationship Data Types

Relationship data types (or REFs) are used as pointers within the database, and the use of these requires the Objects option of the database. With this data type, a row in an insurance claim table could point to a row in the invoice table without having to store the invoice number on the claim record or the claim number on the invoice record.

Extended Versus a Restricted ROWID

As you learned earlier, each row, be it table or index, in the database has an address. You can examine this address by querying the ROWID pseudo column. This ROWID is a string representing the address of the row that has the data type ROWID. The restricted ROWID format is that which was used in versions prior to Oracle 8. Beginning in Oracle 8, Oracle incorporated an extended format for ROWIDs to efficiently and effectively support partitioned tables and indexes as well as tablespace relative data block addresses without any ambiguity.

Restricted ROWID

The format of the restricted ROWID is block.row.file. block refers to the hexadecimal string that represents the data block of the data file that contains the given row. The length of this portion of the ROWID is operating system dependent. row refers to a four-digit hexadecimal string that identifies the specific row in the data block. The first row in a data block has a value of 0. file is a hexadecimal string that refers to the database file containing the row. The first data file in the database has the number 1 (typically belonging to the SYSTEM tablespace), and the length of this string is operating system dependent.

Extended ROWID

The extended ROWID requires 10 bytes of on-disk storage and is displayed using 18 characters that have similar components to the restricted ROWID. The format is as follows:

data_object_number.relative_file_number.block_number.row_number

The data object number is assigned to each data object (table, index) when it is created. Data object number is unique within the database and takes up 32 bits. Relative file number is unique to each file within a tablespace; relative file number needs 10 bits. Block number is the position of the block containing the row within the given file; this requires 22 bits. Row number identifies the position of the row directory slot in the data block header and takes up the remaining 16 bits.

Extended ROWIDs are stored as base 64 values. They can contain the characters A-Z, a-z, and 0-9 as well as the plus sign (+) and the forward slash (/). You can use the DBMS_ROWID package to enable you to interpret the extended ROWID contents.

Although the restricted form is still supported for backward compatibility, all tables that have ROWID returned in a query will be returned in the extended format.

Because segments can only reside in only one tablespace, the Oracle system tables can be used to determine the tablespace in which the row resides. The relative file number within the given tablespace can be used to locate the file, and the block number will be used to locate the block in the tablespace and data file containing the row. The row number is then used to locate the row directory for the row. In this way, Oracle can use the ROWID to locate any row within a database.

You now have an understanding of the different data types that can reside in a table and the way that Oracle uses the ROWID to uniquely find the row in the database. We now need to determine what exactly is meant by a row and its structure because rows make up tables.


Structure of a Row

Everything in the database has a structure; rows are no exception. Row data is stored within database blocks as records of varying lengths. The columns in a row are stored in the order in which they are defined in the table, and any NULL columns that are trailing columns are not stored.

Nontrailing NULL columns require a single byte of storage for each column length.

Each row in any table may therefore have a different number of columns depending on where NULL values occur. Each row in a table, however, has a row header and row data. The row header stores the number of columns in the row, any row chaining information that may be relevant, and the status of any row locks. In the row data portion of the row, for each column, the Oracle Server stores the column length and value (1 byte for the length for each column that does not exceed 250 bytes in length; larger columns require 3 bytes for the column length). The value is stored immediately following the column length.

Adjacent rows in the table do not require any spaces between them, but each row in the block has its own slot in the row directory in the block header that points to the beginning of the row.

Now that you understand the makeup of the row, let's create a table to contain them.


Creating Regular and Temporary Tables

The CREATE TABLE command is used to create relational or object tables. Relational tables are the basic structure used to hold user data. Object tables are used to hold tables that have an object type for a column definition. Object tables are explicitly defined to hold object instances of a particular type (but we will not cover object tables for this exam).

Oracle suggests, rightfully, that locally managed tablespaces are best for table creation because they help to avoid fragmentation.

The following is an example of a CREATE TABLE script:

CREATE TABLE friends(
Fname varchar2(35),
Lname varchar2(35),
Birthday date,
Email_address varchar2(100),
Street_addr1 varchar2(100),
Street_addr2 varchar2(100),
Street_addr3 varchar2(100),
City varchar2(50),
State_abbr char(2),
Zip_code number)
TABLESPACE mydata;

This example table creates a simple address book table of friends that the user wants to maintain.

Certain privileges are required to create tables. If your users are going to be creating tables only in their own schema, they need to have CREATE TABLE privileges. For a user to create tables in other people's schemas, they will have to be granted the CREATE ANY TABLE privilege.

If you are creating the table in a dictionary managed tablespace and want to be able to control the storage parameters associated with the table, you can use the following command:

CREATE TABLE friends(
Fname varchar2(35),
Lname varchar2(35),
Birthday date,
Email_address varchar2(100),
Street_addr1 varchar2(100),
Street_addr2 varchar2(100),
Street_addr3 varchar2(100),
City varchar2(50),
State_abbr char(2),
Zip_code number)
STORAGE (INITIAL 50K
NEXT 50K
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS UNLIMITED)
TABLESPACE mydata;

This STORAGE clause allocates the first extent of 50KB (the INITIAL parameter). Each additional extent needed will be 50KB (NEXT). There will be at least one extent allocated (MINEXTENTS) and no limit to the number of extents that can be allocated (MAXEXTENTS UNLIMITED). There will be no increase in size in any of the NEXT extents that are allocated (PCTINCREASE=0).

Table 12.1 provides a set of block utilization parameters that are still applicable to dictionary managed tablespace based tables. These parameters are deprecated with Automatic Segment Space Management.

Table 12.1. Block Utilization Parameters

Block Utilization Parameters

Description

PCTFREE

Specifies the percentage of the space that will be reserved in each data block to be filled with updates. Value must be between 0 and 99. 0 means that the entire block will be filled by inserts of new rows.

Default is 10 (reserving 10% of each block for updates to existing rows and allows 90% of the block to be filled with inserts).

PCTUSED

The amount of used space that will be maintained for each data block in a table. A block becomes a candidate for row insertion when its used space falls below PCTUSED (which is an integer between 0 and 99 with a default of 40).

PCTUSED + PCTFREE <= 100%

INITRANS

Initial number of transaction entries allocated within each data block allocated to the table. Value can range from 1 to 255 and defaults to 1. INITRANS ensures that a minimum number of transactions are allowed to update the block. Ordinarily, this value should not be changed.

MAXTRANS

The maximum number of concurrent transactions that can update a data block. This limit only applies to inserts, updates, and deletes. SELECT statements don't apply. Value can range from 1 to 255, and the default is a function related to data block clause.

If the TABLESPACE clause is omitted, the table will be created in the user's default tablespace.

Temporary Table Creation

Temporary tables are created to hold session level private data that exists only for the duration of the session. Temporary tables are created similarly to regular tables, but by using the additional GLOBAL TEMPORARY clause.

The following command creates a temporary table that can be either transaction-or session-specific.

CREATE TABLE addresses_temp
AS SELECT * FROM addresses;

Transaction Specific

For transaction-specific temporary tables, the data within the table exists exactly for the duration of the transaction but goes away at the end of the transaction.

Session Specific

Session-specified temporary tables maintain their data for the duration of the session.

The clauses that control the duration of the data rows within the temporary table are as follows:

  • ON COMMIT DELETE ROWS is used to specify that the rows are only to be visible and available throughout the duration of the transaction.

  • ON COMMIT PRESERVE ROWS is used to specify that rows are to be fixable for the entire session.

Global temporary tables retain their data only for the duration of a single transaction or session, and the data in a session is private to that session, although any session or transaction can access the temporary table and manipulate its own data within. Data Manipulation Language (DML) locks are not acquired on the data within, and DML does not generate redo logs. You can create indexes, views, and triggers on temporary tables just like you can on regular tables. You can use the Import/Export utilities to export the definition of the temporary table and import it again; however, even if you use the ROWS option, no rows of data will ever be exported.

If you choose to build your tables in dictionary managed tablespaces, you will have to maintain some storage parameters for the tables. These are outlined in the following section.


External Tables

External tables are read-only tables whose data resides outside the database in an external operating system resident flat file but whose definition resides in the database. You can query the external table just as if it were a regular table. You specify the external table by adding the ORGANIZATION EXTERNAL clause to your CREATE TABLE command.

You need to develop the specifications for the external file using formats similar to that used in SQL Loader control files.

First, you need to create the directory objects in Oracle that refer to the operating system directories that contain the data sources that are the destination for bad records and the destination for log files:

CREATE OR REPLACE DIRECTORY datadir as 'd:\datadir';
CREATE OR REPLACE DIRECTORY logdir as 'd:\logdir';
CREATE OR REPLACE DIRECTORY baddir as 'd:\baddir';
Next, grant permissions on these directories.
GRANT READ ON DIRECTORY datadir TO user1;
GRANT WRITE ON DIRECTORY logdir TO user1;
GRANT WRITE ON DIRECTORY baddir TO user1;

Now, define the external table:

CREATE TABLE ext_addresses(
Fname varchar2(35),
Lname varchar2(35),
Birthday date,
Email_address varchar2(100),
Street_addr1 varchar2(100),
Street_addr2 varchar2(100),
Street_addr3 varchar2(100),
City varchar2(50),
State_abbr char(2),
Zip_code number)
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY datadir
ACCESS PARAMETERS
(badfile baddir:'external_addresses.bad'
Logfile logdir:'external_addresses.log'
Records delimited by newline
Fields terminated by ','
optionally enclosed by '"'
missing field values are null
(Fname, Lname, Birthday, Email, Street_addr1,Street_addr2,
Street_addr3, City, State_abbr, Zip_code)
)
)
Location ('addresses.dat'
)
REJECT LIMIT UNLIMITED;

You can change the table definition on these the same as you can for any other table, using add, modify, or drop columns with the ALTER TABLE command. You can DROP the external table (although this removes only the definition, not the operating system file, even if you are using OFS).

The following lists some limitations on the use of external tables:

  • You cannot generate indexes on external tables.

  • You cannot perform DML on the data; the table is read-only.

  • Oracle's security can be bypassed if a user has access to the underlying operating system files and the authority to change the contents of those files.

It is important to understand how storage structures are managed in Oracle even if you are not using dictionary managed tablespaces.


Managing Storage Structures

Some of the storage parameters and all block utilization parameters can be altered with the ALTER TABLE command. The command won't fail on locally managed tablespace tables, but the effects will be irrelevant. The storage parameters that they are responsible for maintaining are maintained by the bitmaps in the segments and not in the parameters stored in the data dictionary.

The following code shows a generic example of how a table's storage parameters would be changed using an ALTER TABLE command:

ALTER TABLE tablename
{[storage clause and block utilization clauses]};

Different effects occur depending on the parameters that you alter. The most common of these follow:

  • NEXT is the value for the next new extent. Subsequent extents will be increased by the value of PCTINCREASE. The value of NEXT will be rounded to a value that is a multiple of the block size that is greater than or equal to the value specified.

  • PCTINCREASE will change in the data dictionary immediately but will not be used to recalculate the NEXT until the next extent is ready to be allocated.

  • MINEXTENTS will be changed to any value that is less than or equal to the current number of extents in the table. This will only have a noticeable effect if the table is truncated.

  • MAXEXTENTS can be set to any value that is equal to or greater than the current number of extents in the table and can be set to UNLIMITED. This change takes effect immediately.

The value for INITIAL cannot be modified for a table.

Manually Allocating Extents

Not only can extents be allocated automatically by Oracle, the DBA can, if necessary, allocate extents to a table manually. This can be done to control and even out the distribution of extents across data files or as a preemptive measure before bulk loading data to avoid dynamic extension of tables.

The general format for this is as follows:

ALTER TABLE tablename
ALLOCATE EXTENT (SIZE xxxK
DATAFILE '<tablespace's data file>';

If SIZE is omitted, Oracle uses the NEXT_EXTENT size from DBA_TABLES as the size to allocate for the extent. This does not affect the value of NEXT_EXTENT regardless of what PCTINCREASE is set to.

The DATAFILE specified must be a file that belongs to the tablespace to which the table belongs or the statement will generate an error. If the DATAFILE clause is not specified, Oracle allocates the extent in one of the tablespace's files that contains the table.

It often becomes necessary in the course of a DBA's career to move objects around, to make things run better, to alter the structure of objects and the places that they are stored. The next section covers many of the objects that you will encounter in your adventures moving things around.


Regular Table Operations

You will, doubtless, at some point need to reorganize a table, move a table from one tablespace to another, redefine an entire table or portions of tables, or perform other interesting tasks. This section discusses these operations.

Reorganizing Tables

Reorganizing tables can eliminate row migration both offline (as you have been able to historically) as well as online.

Redefining Tables

Occasionally you will need to redefine a table that is in production. Historically, you would have needed to lock the table in shared mode to perform this action. In effect, this shuts out all DML access. In Oracle 9i, you can now redefine tables while the database is online, and the table is accessible to DML operations for the duration of the process.

During the redefinition process you can

  • Add or rename columns

  • Drop columns that are not part of the primary key

  • Convert between regular table and partitioned table and back to regular table

  • Re-create the table to reduce block level fragmentation

  • Add the parallel query capability

  • Change the storage parameters

There are, naturally, some restrictions for online redefinition. These include

  • The table in question must have a primary key.

  • The source table to be redefined and the target table must have identical primary key columns.

  • The table cannot have either a BFILE column or a LONG column.

  • The table can have LOB columns.

  • The table cannot have any user-defined types.

  • The table cannot be a part of a cluster.

  • The table cannot be an overflow table for an index-organized table.

  • The table cannot belong to either SYS or SYSTEM.

  • The table cannot have any materialized views or materialized view logs defined on it.

  • The new column cannot be declared as NOT NULL.

  • Redefinition must belong to the same schema.

Redefinition Process

The steps necessary to perform the online redefinition are as follows:

1.
Verify that the table can be redefined online by invoking the CAN_REDEF_TABLE procedure of the DBMS_REDEFINTION package.

2.
Create the interim table with the same schema definition and characteristics as the source table that you want to redefine.

3.
Start the redefinition process by invoking the START_REDEF_TABLE procedure in the DBMS_REDEFINITION package:

DBMS_REDEFINITION.START_REDEF_TABLE ('myschema', 'address', 'redef_address');

Optionally, you can enter column mappings as an additional argument. If the column mappings are not provided, Oracle assumes that the columns are the same names in both tables.

4.
Create any indexes, constraints, triggers, and grants on the target table that are created on the source table, but create them with different names. Any referential integrity constraints have to be created on this interim table with the DISABLE option. Upon successful completion of the redefinition, Oracle enables these constraints.

5.
Periodic synchronization of the interim table with the original can be done, particularly if many DML operations are being done against the original. This can be done with the DBMS_REDEFINITION.SYNC_INTERIM_TABLE package procedure.

6.
Complete the redefinition by invoking the FINISH_REDEF_TABLE procedure of the DBMS_REDEFINTION package. At this point, the table is acquired with an exclusive lock, and there can be no active DML occurring against the table at this point.

During this step, the original table is redefined with all the characteristics, indexes, constraints, triggers, and grants that you defined on the interim table, and all referential constraints are enabled.

7.
Optionally, you can rename the indexes.

If you encounter any errors or if you want to abort the redefinition for any reason, you must invoke the ABORT_REDEF_TABLE procedure in the DBMS_ REDEFINITION package.

Moving Tables

In Oracle 9i, you can now move nonpartitioned tables from one tablespace to another without the need to perform an export/import operation. After moving a table, you will have to rebuild the indexes to avoid having the indexes be in an unusable state. In this way, you can segregate hot tables off to their own tablespaces or distribute I/O over more devices. The command used to move a table to another tablespace is as follows:

ALTER TABLE addresses MOVE TABLESPACE mydata2;

Truncating Tables

If you want to remove all the data from a table, lower the high water mark, and still retain the definition of the table, you can issue the trUNCATE command to accomplish this:

TRUNCATE TABLE addresses;

You can, optionally, drop or reuse the storage associated with the truncated table to undefine the segments associated with the table.

Because trUNCATE TABLE is a Data Definition Language (DDL) command, no undo is generated. Therefore, it is important that you be sure that you really want to truncate any table before you issue the command. Rolling back will not get the data back. For this same reason, ON DELETE TRiggers don't fire on a TRUNCATE command.

The indexes that correspond to the table being truncated are also truncated (no data, no indexes).

You cannot truncate a table being referenced by a foreign key.

Dropping Tables

If you simply want to remove the entire table from the database, you can issue the DROP TABLE command:

DROP TABLE addresses;

Again, remember that you cannot simply drop a table being referenced by a foreign key.

We have now created a table, manipulated the table at the table level, and determined the way to proceed with some of the common maintenance that might need to occur on a table while that table is online. Now let's examine what can occur at the column level concerning maintenance.

When the table is dropped, the extents used by the table are all released.

Optionally, you can add the CASCADE CONSTRAINTS option if the table is the parent in a foreign key relationship.

You can, similarly, make alterations to tables themselves. The following section addresses many of the operations that you can perform on the table's structure.


Column Operations

Often, you will need to perform maintenance on a table at the column level.

Dropping a Column

Designs change. It will often become apparent after a design has been implemented that some of the design assumptions were inaccurate, and a column will need to be removed from the table. In previous releases of the database, this would have been tricky, but in Oracle 9i it has been simplified. All you have to do to drop a column is ALTER the table and DROP the column:

ALTER TABLE addresses DROP Street_addr3;

Dropping columns can take a significant amount of time if a significant amount of data is being deleted from the table as a result of the drop. For this same reason, dropping a column may require a significant amount of undo space. If you want to minimize the impact of the drop on undo space, you can specify that checkpoints occur periodically (for example, every 2,500 or 5,000 rows). The primary drawback to this option is that the table is marked invalid until the operation completes. If the instance fails during the operation, the table will remain invalid on startup, and the operation will have to be completed to remove the invalidation. If this occurs, the command to continue with the operation follows:

ALTER TABLE addresses DROP COLUMNS CONTINUE;

There are, of course, restrictions on dropping columns from tables as follows:

  • You cannot drop a column from an object type table.

  • You cannot drop a column from nested tables.

  • You cannot drop all the columns in a table.

  • You cannot drop a partitioning key column.

  • You cannot drop a column from a table owned by SYS.

  • You cannot drop a parent key column.

  • You cannot drop a column from an index-organized table if the column is a primary key.

Unused Columns

Instead of immediately removing a column from a table, you can mark the column as unused and then remove it later. This has the advantage of speed and does not cause additional undo space to be created at busy times. Marking a column as unused does not reclaim the disk space because the data is not removed. Columns that have been marked as unused can be removed later from the table.

Unused columns are interesting; they pretend that they are not actually a part of the table. You cannot query the columns nor do they appear if you describe the table. A column with the same name and attributes as the column marked as unused can be added to the table.

Because the column cannot be seen when you describe the table or when you query it, you need a means to determine tables with unused columns. To do this, you have to query the DBA_UNUSED_COL_TABS data dictionary view. This query does not identify the name of the unused column, only that an unused column exists in the table. You cannot mark an unused column as used again, so to get rid of the column, you need to issue the following command:

ALTER TABLE addresses DROP UNUSED COLUMNS;

A LONG or a LONG RAW column that is set to unused but has not yet been dropped will prevent the addition of a LONG or a LONG RAW column to the table, even though you can't see the unused column.

Adding Columns

Additional design issues may come to light that suggest that you might need to capture even more information connected to a given table. For example, you can add a column to include cell phone numbers in a table. In this case, even though phone numbers are numbers, they don't participate in mathematical operations, so they can be stored as character data. And because there are international phone numbers with country codes, you must make the column large enough for any country codes, parentheses, and slashes that the user might want to add:

ALTER TABLE addresses ADD (cellphone_number varchar2(20));

Altering Columns

Finally, you may need to change the characteristics of a column. You may need to change a column's size because needs have changed and now the column must store more information. Or you may need to change a column's data type (we stored ZIP codes as a number, and people still keep insisting on averaging them). To change the size, you can use the following statement:

ALTER TABLE addresses MODIFY zip_code varchar2(15);

Now, where do we get information on a table? Who owns the table? Is the table part of a cluster? What are a table's columns and similar information?


Data Dictionary Information on Tables

You can get information, naturally, out of the data dictionary concerning tables. This information can be used to assist in documenting the database, or to help the DBA find the locations and attributes of the tables in your database. Table 12.2 gives you the most useful data dictionary views and the kind of information that they will help you find.

Table 12.2. Data Dictionary Views for Tables

View

Description

DBA_TABLES

Provides information on relational tables. Included are storage information, tablespace location, space utilization information, and table type.

DBA_TAB_COLS

Provides all table and view columns.

DBA_TAB_COMMENTS

Shows all the comments on tables and views.

DBA_COL_COMMENTS

Shows all the comments on all the columns.

DBA_EXTERNAL_TABLES

Describes the attributes, including the directory name and owner for external tables.

DBA_TAB_COL_STATISTICS

Provides information on analyzed columns.

DBA_CLUSTERS

Provides information on all the clusters in the database, including the name, tablespace, and owner.


Exam Prep Questions

1:

You were in the process of dropping the invoice_number column in the orders table. The table was marked as invalid while the command was processing. While the column drop was in process, suddenly the instance failed. You restart the instance and notice that the orders table is still invalid. You want to be able to access the data in the table and finish the drop column that you had in process at the failure point. What could you do? [check all that apply]

  • A. Reissue the ALTER TABLE orders DROP COLUMN invoice_number command.

  • B. Issue the ALTER TABLE orders DROP COLUMNS CONTINUE command.

  • C. Truncate the table.

  • D. Drop the table and start over fresh.

  • E. Mark the column as unused and worry about it later.

A1:

Answer B is correct; you can issue the ALTER TABLE orders DROP COLUMNS CONTINUE command to complete the drop and return the table to a valid state. Answer A is incorrect. Because the table is currently invalid, you won't be able to alter it. Answer C is incorrect; if you truncate the table, you will not only no longer be able to get to the data that you have just truncated, you also will not finish removing the column. Answer D is incorrect; dropping the table will mean that you lose all the current data. Answer E is incorrect; simply marking the column as unused will probably fail and will not re-mark the table as valid.

2:

You are logged in to the database as user123, and you issue the following command:

CREATE TABLE contacts (
Fname varchar2(35),
Lname varchar2(35),
Birthday date,
Email_address varchar2(100),
Street_addr1 varchar2(100),
Street_addr2 varchar2(100),
Street_addr3 varchar2(100),
City varchar2(50),
State_abbr char(2),
Zip_code number);

As soon as it completes, you realize that you forgot to specify a tablespace into which you want the new table built. You recall that user_users data dictionary view gives you information about user defaults. You issue the following query to determine what tablespace the table is most likely to be built in:

SELECT username, default_tablespace, temporary_tablespace
FROM user_users
WHERE username = 'USER123';

The query returns

no rows selected

Where is the most likely place for the table to have been built?

  • A. The USERS tablespace

  • B. The DATA tablespace

  • C. The temporary tablespace

  • D. The SYSTEM tablespace

A2:

Answer D is correct; the most likely place for the table to be located is in the SYSTEM tablespace because the user didn't have an assigned default tablespace. Answers A and B are incorrect because user123 didn't have USERS as the default tablespace nor the DATA tablespace as the default tablespace for the user. Answer C is incorrect; temporary tablespaces can hold no permanent objects.

3:

Based on the information provided in question 2, where would be the most likely place to look for the location in which the table was actually built?

  • A. The control file

  • B. The DBA_TABLES view

  • C. The V$TABLES view

  • D. The DBA_TAB_COMMENTS view

A3:

Answer B is correct; the DBA_TABLES view (as well as the USER_TABLES view and the ALL_TABLES view) will provide information on which tablespace a table is located in. Answer A is incorrect; the control file does not contain table information. Answer C is incorrect; there is no V$TABLES view in the data dictionary. Answer D is incorrect; the DBA_TAB_COMMENTS will provide information on the comments on tables but not the location of the tables.

4:

The backup_addresses external table needs to be dropped from the database because it is no longer needed. Which of the following statements are true about dropping this table? [choose all that apply]

  • A. The data in the table will be completely removed from the tablespace and the data files in which its segments reside.

  • B. The definition will be removed from the data dictionary.

  • C. The data will remain available in the data file.

  • D. You can recover the space with the INCLUDING CONTENTS command.

  • E. You should export the data right before you drop the table in case you need to get the data back.

  • F. If you are using OMF, the data files will be removed from the operating system.

A4:

Answers B and C are correct; the definition will be removed from the data dictionary, but the data will remain in the independent operating system flat file. Answer A is incorrect; external tables are not located in any tablespaces. Answer D is incorrect. There is no space taken up in the database because of the external table's existence; therefore, none will be recovered. Answer E is incorrect; you needn't export the data because it remains in the external operating system file in readable format. Answer F is incorrect; dropping the external table will not for any reason or in any circumstance cause Oracle to delete the data file.

5:

You build a table in a dictionary managed tablespace. Which columns from DBA_TABLES are required to help the DBA determine what the size of the next extents will be whenever the table requires it? [select all that apply]

  • A. PCT_INCREASE

  • B. BLOCKS

  • C. EMPTY_BLOCKS

  • D. INITIAL_EXTENT

  • E. NEXT_EXTENT

A5:

Answers A and E are correct; NEXT_EXTENT shows the size the very next extent will be, and PCT_INCREASE shows the amount that will increase for the following extent. Answers B and C are incorrect; the number of blocks (either empty or that exist in the table) does not play a part in the determination of the size of extents. Answer D is incorrect; it will only lead you back to the size of the first extent in the table.

6:

Which kind of table is created to allow for performance increases and to distribute processing across several tablespaces?

  • A. External tables

  • B. Index-organized tables

  • C. Regular tables

  • D. Partitioned tables

A6:

Answer D is correct; partitioned tables can be used to distribute data and therefore processing over different tablespaces. Answer A is incorrect; the data file that underlies external tables can reside in exactly one place on the operating system. Answer B is incorrect; index-organized tables are used to store the data in the leaf blocks of the index but do not distribute data across several tablespaces. Answer C is incorrect; regular tables are the tables that data is typically stored in.

7:

Which kind of table would you create to provide users with fast, primary key based access to the data without reliance on index searches?

  • A. External tables

  • B. Index-organized tables

  • C. Regular tables

  • D. Partitioned tables

A7:

Answer B is correct; index-organized tables provide fast access to data based on keyed access because the data is stored in the key. Answer A is incorrect; external tables cannot be indexed. Answer C is incorrect; regular tables can be indexed, but it still requires access to the index and then access to the data. Answer D is incorrect; partitioned tables are often faster but not necessarily by primary key, more often by partition key.

8:

Which statement is true about segments?

  • A. Each table in a cluster has its own segment.

  • B. All the data in a table segment must be stored in one tablespace.

  • C. The data in a regular table segment can be distributed across tablespaces.

  • D. Nested tables within a table use that parent's segment for storage.

A8:

Answer B is correct; all the data in a regular table segment has to be located in a single tablespace. Answer A is incorrect; all the tables in a cluster share blocks and therefore share a single segment. Answer C is incorrect; the data in a partitioned table can be distributed across tablespaces because they are located in different segments. Answer D is incorrect; the nested table has its own storage segment independent of the parent table.

9:

Examine the following statement:

TRUNCATE TABLE addresses;

What is true about this command? [select all that apply]

  • A. Only the data is affected; the indexes remain valid and usable.

  • B. All data is deleted from the table.

  • C. Associated indexes are also truncated.

  • D. Undo data is generated for the action.

A9:

Answers B and C are correct; the data is deleted from the table, and the associated indexes are also truncated. Answer A is incorrect; the indexes are truncated as well as the data and therefore contain no rows. Answer D is incorrect; undo data is not generated for a truncate operation.

10:

A user issues the following command on a one million row table

TRUNCATE TABLE mytable;

He then realizes that he made a mistake and wanted to truncate the mydata table. He issues the rollback command. What will be the result?

  • A. The table's data will be restored immediately.

  • B. The table's data will be restored, but it will take a while for the rollback to complete.

  • C. The table will remain empty because you can not roll back a trUNCATE command.

  • D. You can't truncate a regular table; the data will remain in the data file.

A10:

Answer C is correct; you cannot roll back from a trUNCATE command. Answers A and C are incorrect; trUNCATE cannot be rolled back. Answer D is incorrect; you cannot truncate an EXTERNAL table, and the data will remain in its data file, but external was not specified in this case.


Chapter 13. Managing Indexes

Terms you'll need to understand:

  • CREATE INDEX

  • CREATE UNIQUE INDEX

  • CREATE BITMAP INDEX

  • ALTER INDEX

  • DEALLOCATE UNUSED

  • REBUILD

  • VALIDATE STRUCTURE

  • DROP INDEX

  • DBA_INDEXES

  • DBA_IND_COLUMNS

  • DBA_OBJECTS

  • INDEX_STATS

  • CREATE_BITMAP_AREA_SIZE

Concepts you'll need to master:

  • List the different types of indexes.

  • Describe the uses of different indexes.

  • Create different types of indexes.

  • Reorganize indexes.

  • Drop indexes.

  • Get index information from the data dictionary.

  • Monitor index usage.

And now we launch on our discussion of indexes. Indexes are optional structures associated with tables and clusters. Indexes can be created on one or more columns of a table to speed SQL statement execution on that table. In this chapter we will discuss the different types of indexes and when you would choose one type over another.


Different Types of Indexes and Their Uses

An index is, typically, a tree structure that allows a query to directly access a row in a table. Indexes can be classified based on their logical design or on the physical implementation.

Logical Index Classifications

The logical classification groups indexes together based on an application perspective of the index. The following list describes the various logical classification indexes:

  • Single column Has only one column in the index key; for example, claim_number might be the key for a claim table.

  • Concatenated Also known as composite indexes, these are indexes created on multiple columns in a table. The columns that are concatenated do not need to be in the same order as the columns appear in the table, nor do they need to be adjacent in the table. The maximum number of columns permitted to be in a composite key is considered to be 32; however, the combined size of all the columns in the index cannot exceed roughly one-third of the size of the data block.

  • Unique index Guarantees that no two rows of a table have duplicate values in the column or columns that define the index. Therefore, an index key in a unique index can point to one and only one row in the table.

  • Nonunique index In this index, a single key can point to one or to multiple rows associated with it.

  • Function based Created whenever you are using functions or expressions that involve one or more than one column in a table that is being indexed. Function-based indexes precompute the values of the function or expression on which they are based and store that value in the index. They can be created either as a B-tree index or a bitmap index.

    Function-based indexes allow you to create more powerful sorts by allowing you to perform sorts that are not case sensitive by creating indexes with the UPPER and LOWER functions along with the descending order sorts with the DESC keyword. You can even create linguistic sort based indexes with the NLSSORT function. You can precompute the values of computationally intensive functions and store the value in the index for expressions used often on a given column or columns. In this way, you can access the index to access the value and not force the recomputation of the value, greatly improving query execution performance.

    The following initialization parameters need to be defined if you are going to create function-based indexes:

    • QUERY_REWRITE_INTEGRITY needs to be set to trUSTED.

    • QUERY_REWRITE_ENABLED needs to be set to trUE.

    • COMPATIBLE needs to be set to at least 8.1.0.0.0 or greater.

  • Domain Application-specific indexes (for example, Spatial) that are created, managed, and accessed by routines supplied by an index type. It is known as a domain index because it indexes data in application-specific domains. As yet, only single-column domain indexes are supported and can be built on columns that have scalar, object, or LOB data types.

Physical Index Classifications

The physical classification of an index is based on the way the indexes are stored. The next few sections cover physical index classifications in more detail.

Partitioned

Partitioned indexes are used for large tables as a means to store the index entries corresponding to an index in several segments. Partitioning of indexes allows an index to be spread across several different tablespaces, thereby decreasing contention for index lookup and increasing manageability. An index partition can be created on a one-to-one basis with a table partition.

Nonpartitioned

Nonpartitioned indexes are the norm and are created in a single tablespace. They are covered in the remainder of this chapter.

B-Tree

Although the vast majority of indexes use a B-tree structure, the term B-tree (short for binary tree) is typically associated with indexes that store a list of ROWIDs for each key.

The top of the B-tree index is the root, which contains entries that point to the next level in the index. One level farther down are branch blocks that in turn point to blocks at the next level in the index. This continues until the lowest level is reached, where there are leaf nodes, each containing index entries that point to rows in the table. Leaf blocks are doubly linked to facilitate scanning the index in an ascending or descending fashion. Ascending is the typical means of storing and accessing.

Figure 13.1 shows, graphically, what a B-tree structure would look like. Although this is a simple example, you can see how each leaf is doubly linked in order, so you can traverse the tree in obverse and inverse order.

Figure 13.1. A typical B-tree structure.

Leaves contain the index entries that have the following components:

  • An entry header that stores the number of columns and locking information for the index.

  • Key column length value pairs. These pairs define the size of the column in the key followed by the value for that column. The number of pairs equates to the number of columns in the index.

  • ROWID of a row that contains the key values for the index.

  • Key values in a B-tree index are repeated if there are multiple rows with the same key value.

  • There is no index entry for rows that have all key columns that are NULL; therefore, WHERE clauses that specify NULL or NOT NULL will always result in a full table scan.

  • Restricted ROWID is used to point to the rows of the table. This is possible because all the rows belong to the same segment in the same tablespace.

Oracle maintains all the indexes whenever DML operations are carried out on the table.

Whenever there is an insertion of an index due to an insertion of a new index value in the table, the index entry is inserted into the appropriate block.

If deletions occur in the table that result in a deletion in the index, the index entry is logically deleted. The space consumed by the index entry will not be available for reuse until all the entries in the given block have been deleted.

Updates that occur to key columns result in a logical delete and a physical insert to the index. PCTFREE for dictionary managed tablespaces has no effect on the index except at the time of creation. New entries may be added to index blocks even if the amount of space remaining is less than that specified by PCTFREE.

B-tree indexes are highly suited for high cardinality columns. Updates on B-tree indexes are relatively inexpensive; however, they are somewhat inefficient for queries that use the OR operator in the predicate. B-tree indexes are useful for OLTP environments.

Bitmap

It is often the case that bitmap indexes are more advantageous than B-tree indexes, depending on the situation.

If a table has millions of rows but the key columns have a low cardinality (very few distinct values in relation to the number of rows), bitmap indexes may be preferable to B-tree indexes. For example, values such as gender, marital status, or region of the country may all be good candidates for bitmap indexes.

Examples of times when bitmap indexes are appropriate are as follows:

  • Whenever queries often use a certain combination of WHERE conditions involving the OR operator, bitmap indexes may be a good idea.

  • If there is read-only or low update activity on key columns, bitmap indexes are often a wise choice.

  • Unique indexes are not good candidates because cardinality is one-to-one.

The structure of a bitmap index is organized in a B-tree fashion; however, the leaf nodes each store a bitmap for each key value instead of a listing of ROWIDs. Each bit in the bitmap corresponds to one possible ROWID, and if the bit corresponding to the ROWID is set, the row with that ROWID contains the key value.

Each leaf node contains an entry header that contains the number of columns and lock information. It also contains key values consisting of length and value pairs for each key column; a start ROWID, which contains a file number, a block number, and a row number; and an end ROWID with similar information. Finally, it contains a bitmap segment consisting of a string of bits with the corresponding bit being set whenever the corresponding row contains a key value for that bit and unset when the row does not contain a key value. Oracle has patented the compression algorithm used to store these bitmaps.

The bitmap's B-tree is used to locate the leaf nodes that contain bitmap segments for a given value of the key. The start ROWID and the bitmap segments are used together to locate the rows that contain the given key value. Whenever changes are made to the key columns of the table, the associated bitmaps must be altered correspondingly. These alterations result in the relevant bitmap segments being locked. These locks are acquired on the entire bitmap segment, and that means that any row that happens to be covered by any segment in the bitmap cannot be updated by any other transactions until the locking transaction ends.

Bitmap indexes are useful for low cardinality columns. Updates to key columns are expensive; however, bitmap indexes are efficient for queries that use the OR operator in the predicate. Oracle can use two bitmap segments to facilitate a bitwise Boolean comparison and get a resulting bitmap; this means that Oracle can use bitmaps efficiently in queries that use Boolean in the predicate. They are useful for data warehouse environments because the update of the bitmap occurs so infrequently.

Now that we have covered the kinds of indexes, it is time to look at what is involved in creating them.


Creating Indexes

Indexes are created either in the account of the user who owns the table on which they are built, or in a different account. It is generally the practice to create all indexes in the table owner's account.

There are several things to consider when you are deciding whether to create an index. This section discusses many of these considerations.

Criteria for Creating an Index

You will likely want to create an index if you have queries that frequently retrieve less than roughly 15% of the rows in a large table. The percentage naturally varies somewhat according to the relative speed of a full table scan on that table and that column and on exactly how clustered the row data is in relationship to the index key. The faster the table scan runs, the lower the percentage of rows has to be to really be able to justify the index. The more clustered the row data is with respect to the index column, the higher the percentage should be.

You would create an index to improve the query performance on joins of multiple tables. The index columns in this case would be used for joins. Primary keys (covered in Chapter 14, "Maintaining Data Integrity") already have indexes on them, but foreign keys might be a good candidate for indexing so that the joins perform optimally. Also, foreign key columns are excellent candidates for indexing when there are a significant number of concurrent inserts, updates, or deletes to the parent and child tables. Without this index, the entire child table would have to be locked whenever the parent tables data is changed.

Small tables are not likely to benefit from indexes because full table scans will likely be done regardless of indexing. If queries with relationship to the small table become increasingly long, you may find that the table has grown, and an index might be beneficial.

Columns that might be strong candidates for indexing have one or more of the following characteristics:

  • Relatively unique values

  • A very wide range of values

  • A very small range of values

  • Contain NULL values yet have queries that frequently select only from rows that have a value

The following would not be good candidates for indexing:

  • Columns that have many NULL values and that have queries that do not limit their searches to NON-NULL values are less suitable for indexing.

  • Columns that have LONG and LONG RAW data types cannot be indexed.

The size of a single index entry should not exceed roughly one-half to two-thirds (minus some overhead) of the available space in the data block.

The order that the columns appear in the CREATE INDEX statement can affect query performance. Although Skip Scanning (covered in relation to the Performance Tuning exam) can play a significant role, in general it is better to specify the most frequently used columns first. If you create a single index that includes columns 1, 2, and 3 in the table and then have many queries that access just column 1, the query is speeded up, but a query that accesses just column 2 or just column 3, or columns 2 and 3 together will not gain any benefit from the index.

Any table can have any number of indexes. Oracle does not set a definitive limit. However, it is important to remember that the more indexes you have on a table, the more overhead there is whenever the table or its data is modified, inserted, or deleted.

To create an index in your own schema, Oracle requires that a user meet at least one of the following conditions:

  • The table or the cluster to be indexed must be in that user's schema.

  • That user must have INDEX privilege on the table to be indexed.

  • The user must have the CREATE ANY INDEX system privilege.

More on privileges is covered in Chapter 17, "Managing Privileges."

To create an index in another user's schema, all the following conditions must be true:

  • The user creating the index must have the CREATE ANY INDEX system privilege.

  • The user building the index has to have a quota on the tablespace that is going to contain the index or UNLIMITED TABLESPACE system privilege.

Now that we have discussed the types of indexes, we need to discuss how to create these indexes.

Creating a B-Tree Index

If we were to create a B-tree index on our friends table created in Chapter 12, "Managing Tables," we could use the following syntax:

CREATE INDEX friends_last_names_idx
ON friends(lname)
TABLESPACE useridx;

This syntax creates an index on the last names of the entries in the table.

The general index creation syntax follows:

[View full width]

CREATE [UNIQUE | NONUNIQUE] schema.index ON schema.table(columns) [ASC | DESC] TABLESPACE
   [tablespace] {[PCTFREE integer] [INITRANS integer] [MAXTRANS integer] [STORAGE clause]
   [LOGGING | NOLOGGING] [NOSORT]

The general syntax includes the following keywords:

  • UNIQUE is used to specify a unique index (nonunique is the default).

  • Schema is the owner of the table (when connected to the table name) and the index (when connected to the index). Recall that they can be different schemas.

  • Index is the name of the index you are creating.

  • Table is the name of the table on which you are creating the table.

  • Column is the name of the column on which you are creating the index.

  • ASC|DESC indicates whether the index should be created in either ascending or descending order.

  • Tablespace indicates the tablespace where the new index will be created. If not included, it will be created in the default tablespace of the user creating the index.

  • PCTFREE is the amount of free space to be reserved in each block (this is the percentage of total space minus the amount of space for the block header) at the time of index creation. This is left free for the accommodation of new index entries. PCTFREE is not relevant if the tablespace in which you are creating the index is locally managed. PCTUSED does not make any sense in the case of indexes because index entries must be stored in the correct order. The user can't control when an index block is used for inserts.

  • INITRANS is the number of transaction entries to preallocate in each block. The default (and the minimum) is 2.

  • MAXTRANS is the maximum number of transaction entries that can be allotted concurrently to each block. The default is 255.

  • STORAGE clause is determinant of how extents are allocated to the index. If you are creating the index in a locally managed tablespace, this clause will have no apparent effect.

  • LOGGING specifies that the creation of the index and all subsequent index entries and other operations on the index are logged in the redo log files. Logging is the default.

  • NOLOGGING specifies that the creation of the index and certain kinds of data loading situations will not be logged in the redo log files.

  • NOSORT specifies that the rows are to be stored in the table in ascending order. This means that Oracle does not have to sort the rows when it creates the index and that it assumes that the data is already in sorted order. If this is not the case, the index creation will fail.

If any of the storage parameters are omitted (MINIMUM EXTENT, LOGGING|NOLOGGING, and so on), the defaults of the tablespace take effect.

When determining whether you want to build an index, or what kind of index you want to build, you need to balance your DML needs with your query needs. Indexes tend to speed up queries and slow down DML. You should, therefore, minimize indexes on highly volatile tables.

Always place indexes in a separate tablespace from the table on which they are built and not in a tablespace that has temporary segments being created in it. Although this will not provide extreme gains in performance, it will allow you to recover just the data tablespaces in case of a failure, speeding recovery, and rebuilding the indexes after the database is back online.

Now, how do we create this index in OEM?

Using OEM to Create a B-Tree Index

From a launched OEM Console, expand the database with which you will be working. Expand the Schema folder and select Indexes from the resulting navigator tree. Choose Object from the menu; then choose Create.

Expand the database that resides in the independently launched window and select Index from the list of icons; then click Create. Enter General (index name, index schema, tablespace, table schema, table, columns, and type of index that you are creating), Partitions (if appropriate), Storage characteristics, and Options (parallel or not, the degree of parallelism, and whether to override LOGGING) information in the property sheet and click Create. You can also choose to let OEM automatically define the storage and block utilization parameters based on your estimate of the initial volume for the table, the anticipated table growth rate, the anticipated insert activity on the table, and the order in which rows are to be inserted (sorted or not).

Guidelines

If you are setting extent sizes for index tablespaces, you should attempt to create those tablespaces with uniform extent sizes.

Because you really don't "lose" anything if indexes are lost, only the time to rebuild and the performance hit that your applications might see if the index gets lost, you should probably consider NOLOGGING for large indexes. The performance trade-offs are likely worth the risk. This is also a good reason to segregate indexes into their own tablespaces.

Initial transactions (INITRANS) should, in general, be higher on indexes than on the tables on which they are built. This is the reasoning behind default INITRANS being 2 rather than 1 (as it is for tables); index entries are, typically, smaller than table row entries. This means that there are usually more entries per block.

Again, because indexes work differently from the way tables work, the PCTFREE parameter also works somewhat differently between the two. PCTFREE in index building is used only during the creation of the index to reserve space for more index entries that may need to be inserted into the same blocks. When a key column in the index is updated, there is a logical delete of the original, and an insert of the updated.

You would use a low PCTFREE for indexes created on columns that include system generated numbers, such as sequence numbers. The low PCTFREE is excellent because new indexes are appended to the existing entries, and there is little or no need to insert an entry between two existing entries.

A higher PCTFREE would be more appropriate for an index where a column of an inserted row can take on any value or can fall within a range of values that already exist.

Creating a Bitmap Index

To create a bitmap index, you use the CREATE_BITMAP_AREA_SIZE parameter to specify the amount of memory to be allocated for bitmap creation. This initialization parameter determines the amount of space in memory that will be used for storing bitmap segments. The default value is 8MB; however, a larger value may enable faster index creation. Columns with low cardinality can allow this value to be lowered. As a general rule, the higher the cardinality, the more memory needed for optimal index creation performance.

The CREATE INDEX command is as follows:

CREATE BITMAP INDEX index_name ON table_name(column);

The only noticeable difference between the CREATE INDEX command and the CREATE BITMAP INDEX command is the addition of the BITMAP keyword and the fact that bitmap indexes cannot be unique, so will never take the UNIQUE key word.

Using OEM to Create Bitmap Indexes

The only difference between creating a B-tree index and a bitmap index is the selection of Bitmap as the type.

It is possible to change some (but not all) of the storage parameters for indexes after they are created.


Changing Storage Parameters for Indexes

Parameters that can be modified deal with block utilization. These parameters can be changed with the ALTER INDEX command and include the INITRANS, MAXTRANS, and MAXEXTENTS parameters. These parameters are often altered to allow a higher level of concurrency on any given index block.

Furthermore, much the same as you can manually add an extent to a table, you can manually add extents to indexes.

The following example alters the storage parameters associated with the address_last_name_idx index:

[View full width]

ALTER INDEX addresses_last_name_idx ALLOCATE EXTENT (SIZE 250K DATAFILE 'd:\mydatabases
  \mydb1\addresses_idx.dbf')

You can also deallocate space above the high water mark in an index. This means that if you have allocated space to an index, but that space has never been used (located above the highest point at which data had been stored in the index), you can deallocate that space. The following example shows the syntax that would be used for this:

ALTER INDEX addresses_last_name_idx DEALLOCATE UNUSED;

Manual allocation and deallocation of space for an index follows the same rules as it does for tables.

Index space is automatically deallocated when the table on which the index is built is truncated; table truncation results in index truncation.

Now that we have created indexes and changed their storage parameters, we need to discuss how to reorganize them should the need arise.


Reorganizing Indexes

There are many ways to reorganize indexes. This section discusses the ones that will be both covered in the exam and will also be a big part of your life as a DBA.

Rebuilding Indexes

It is often necessary to rebuild indexes. This can happen for many reasons. The existing index may need to be moved to a different tablespace (it may have inadvertently gotten built in the wrong tablespace originally). The index may contain many deleted entries as can be the case if data older than the current month is deleted, and the date is one of the index columns. These deletions may leave holes in the index. Or an existing normal index needs to be converted to a reverse key index as might be the case when migrating applications from an older version of Oracle on which reverse key indexes were not supported. Finally, one of the main reasons that an index might need to be rebuilt is when the table on which the index was built has been moved to a different tablespace.

Online index rebuilds share the following characteristics:

  • The new index is built using the existing index as its data source rather than the underlying table.

  • Sorts are not needed in the rebuild of an existing index. This can mean far better performance than dropping and rebuilding the index.

  • The old index is automatically deleted after the new index is built. During the rebuild, it is necessary to have sufficient space allocated to accommodate both the old index and the new index in the respective tablespaces.

  • The new index is more efficient because it does not have any deleted entries. Not only is the index likely more efficient, but the space is used more efficiently and effectively.

  • Queries can continue using the existing index while the new index is being built.

The ALTER INDEX statement that allows for the rebuilding of indexes includes the same parameters as the original creation command does as far as the storage parameters, and LOGGING or NOLOGGING. The keywords REVERSE or NOREVERSE can be specified only if the index is a B-tree index.

The following is an example of the code that could be used to rebuild an index online:

ALTER INDEX address_last_name_idx REBUILD ONLINE;

It is important to remember that building indexes and rebuilding them can be time consuming, particularly if the table is large. Before Oracle 8i, tables had to be locked any time you created or rebuilt indexes, preventing DML from occurring simultaneously with the rebuild.

You cannot perform other DDL operations on a table during an online rebuild of any of its indexes.

Rebuilding in Oracle 9i can be done with minimal table locking; however, there are some restrictions as follows:

  • You cannot rebuild an index on a temporary table.

  • You cannot rebuild an entire partitioned index, although you may rebuild each partition or subpartition individually.

  • You cannot deallocate unused space in the rebuild.

  • You cannot change the value of PCTFREE parameter for the index in the rebuild.

Coalescing Indexes

Whenever you encounter index fragmentation, you can choose to rebuild the index, or you can simply coalesce the index. Before you opt for one choice over the other, carefully consider the ramifications of each and choose the option that works best in your given situation.

If you have a B-tree index with leaf blocks that can be freed up for reuse, merging those leaf blocks may provide the most elegant and simple solution as follows:

ALTER INDEX address_last_name_idx COALESCE;

This can have the desired effect of reducing fragmentation.

It is often necessary to determine the validity of an index. The following section discusses this process.

Validating Indexes

You can analyze an index to check all the index blocks for corruption. This does, however, not verify that any of the index values actually correspond to any data in the underlying table.

This analysis has the added effect of populating the INDEX_STATS view with information about the index.

The following code could be used to validate the structure of an index:

ANALYZE INDEX address_last_name_idx VALIDATE STRUCTURE;

After running this command, a query against INDEX_STATS allows you to obtain information about the index, such as the number of blocks, the percent used, number of leaf rows, and number of deleted leaf rows. Oracle suggests that, if the ratio of the number of deleted leaf rows versus the number of leaf rows exceeds 30%, reorganization would be beneficial.

Drop Indexes

It is often advantageous to drop an index right before a bulk load and re-create it afterward or when the index becomes invalid. It is also often necessary to drop indexes that are either used infrequently or never used and to rebuild them whenever the need arises. Often a drop is necessary if the index has become corrupt.

The following code could be used to drop an index:

DROP INDEX addresses_first_name_idx;

Monitor the Usage of Indexes

Beginning in Oracle 9i, one of the most useful new features is the capability to gather statistics about the usage of an index. This information can be gathered and displayed using the V$OBJECT_USAGE view. This allows you to determine that an index is never used and can therefore be dropped. Further, elimination of unused indexes can cut down on the overhead that has to occur whenever DML occurs in the database, and performance will therefore improve. Each time that you specify the MONITORING USAGE clause, the V$OBJECT_USAGE view will be reset for the specified index, and the previous information will be reset or cleared out.

To start monitoring, issue the following command:

ALTER INDEX address_first_name_idx MONITORING USAGE;

To stop monitoring usage, the command is as follows:

ALTER INDEX address_first_name_idx NOMONITORING USAGE;

A query against the V$OBJECT_USAGE view provides the index name (INDEX_NAME), the corresponding table name (TABLE_NAME), the status of monitoring as either on or off (MONITORING), whether the index was used (USED), and the start and end times of the monitoring session (START_MONITORING and END_MONITORING).

But this is just one of the valuable data dictionary views available to assist you with your dealings with indexes. The following section provides information on more.


Index Information in the Data Dictionary

In the data dictionary, you can find several views that provide useful information about the indexes in your database. It is important to note that some of the information may be available only after you have analyzed the indexes.

  • DBA_INDEXES provides information on the indexes themselves. You can use this view to find particular types of indexes (bitmapped, functional, B-tree).

  • DBA_IDN_COLUMNS provides information on indexed columns indexed. You can use information from this view to list the columns that are indexed by each index, including those that participate in concatenated indexes.

  • DBA_IND_EXPRESSIONS provides information on index expressions or function-based indexes.


Exam Prep Questions

1:

Your users are trying to create a domain index (dom_col_key) on a column in a table that has been defined as a VARRAY column. The table already has two other indexes on it. They are getting an error saying that you cannot create an index on an expression with data type. What is the possible reason for the error?

  • A. The table already has too many indexes.

  • B. Domain indexes can't be built on columns that are VARRAY type.

  • C. The users don't have the proper authority to create the index.

  • D. They are using an invalid name for the index.

A1:

Answer B is correct; domain indexes cannot be built on VARRAY columns. Answer A is incorrect; two indexes on a table is not an excessive number. Answer C is incorrect; improper authority would not give you an error concerning the data type. Answer D is incorrect because the error does not indicate that there is an issue with the name.

2:

What kind of index does the following syntax create?

CREATE INDEX address_state_idx
ON address
PCTFREE 10
TABLESPACE mydb1idx
NOLOGGING;

  • A. Bitmap

  • B. B-tree

  • C. Function based

  • D. Reverse key

A2:

Answer B is correct; the syntax stated creates a B-tree index. Answer A is incorrect; to create a bitmap index you need to provide the BITMAP keyword in the CREATE INDEX statement. Answer C is incorrect; there is no function in the CREATE INDEX script. Answer D is incorrect; to create a reverse key index, you need to include the keyword REVERSE.

3:

With your users and developers, you have determined that you need to add the State index to the addresses table. The index has been determined to have the following criteria:

  1. The index will be called address_state_idx.

  2. Because you are only dealing with US addresses and the table is planned to have a million rows, the column's cardinality will be limited.

  3. The index should be created in the indexes1 tablespace.

  4. All extents should be 100KB.

  5. The index is nonunique.

  6. No redo information should be generated for the index creation.

  7. 15% of the block should be free for future entries.

Which of the following commands meets all these criteria and will build the desired index?

  • A.

    CREATE UNIQUE INDEX address_state_idx ON addresses(state)
TABLESPACE indexes1
PCTFREE 15
STORAGE (INITIAL 100K NEXT 100K PCTINCREASE 0)
NOLOGGING;

  • B.

    CREATE BITMAP INDEX address_state_idx ON addresses(state)
TABLESPACE indexes1
PCTFREE 15
STORAGE (INITIAL 100K NEXT 100K PCTINCREASE 0);

  • C.

    CREATE BITMAP INDEX address_state_idx ON addresses(state)
TABLESPACE indexes1
PCTFREE 15
STORAGE (INITIAL 100K NEXT 100K PCTINCREASE 0)
NOLOGGING;

  • D.

    CREATE BITMAP INDEX address_state_idx ON addresses(state)
REVERSE
TABLESPACE indexes1
PCTFREE 15
STORAGE (INITIAL 100K NEXT 100K PCTINCREASE 0)
NOLOGGING;

A3:

Answer C is correct; this will create a bitmap index (low cardinality on the indexed column) that meets all the other requirements. Answer A is incorrect; that will create a unique index, and the specifications stated that it should be nonunique. Answer B is incorrect; the specifications stated that there should be no redo logged on index creation. Answer D is incorrect; the specifications did not include a reverse key index.

4:

After running ANALYZE INDEX claim_id_idx VALIDATE STRUCTURE, you query the INDEX_STATS view and learn that you have a rather high ratio of deleted leaf rows (DEL_LF_ROWS) to leaf rows (LF_ROWS); in fact, the ratio ends up being almost 40%. You decide that you need to reorganize the index to free up some of the extra space, but the space should remain allocated to the index so that it can be reused for new entries. Which command or commands would allow you to perform this task while maintaining the minimum impact on the users who are running queries on the system? [select all that apply]

  • A. DROP INDEX followed by CREATE INDEX

  • B. ALTER INDEX REBUILD

  • C. ALTER INDEX COALESCE

  • D. ALTER INDEX DEALLOCATE UNUSED

A4:

Answer C is correct; you will need to run the ALTER INDEX COALESCE command to avoid impacting users who are running queries that will need to access the index while the reorganization is in process. Answer A is incorrect; dropping the index and re-creating it would have detrimental effects on the users on the system. Answer B is incorrect; ALTER INDEX REBUILD would eliminate the gaps in the leaf blocks, but Oracle locks the base table whose index is about to be rebuilt, and no changes to the data in the base table can occur. Answer D is incorrect; you would have a detrimental effect on users and would not eliminate the holes in the leaf blocks.

5:

You have been monitoring the usage of an index that you believe to be underused on a table. You find that the index is used extensively but only during the first week of the month, when Accounting is running month-end processing. The rest of the month, the index is used only rarely despite the fact that it is an actively updated table. What could you do to speed up processing during the majority of the month, yet allow queries to run as rapidly as possible during the month-end processing?

  • A. Drop the index; it is obviously used only 25% of the time.

  • B. Move the index to another tablespace.

  • C. Drop the index after the month-end processing and rebuild it right before the next month-end processing.

  • D. Rebuild the index immediately before the month-end processing.

A5:

Answer C is correct; you can drop the index right after month-end processing is complete so that the inserts and updates won't have to update the indexes when they aren't being used and then rebuild the index right before the period when the index is heavily used. Answer A is incorrect; the index is heavily used for that one week of the month, and the index, at that point, is very advantageous. Answer B is incorrect; moving the index won't have any effect on the use of the index. Answer D is incorrect; rebuilding the index won't cause it to be used more or less, only use space more efficiently.

6:

Which statements are true in relationship to the number of indexes on a table? [select all that apply]

  • A. Every column in a table that is subject to update will see update performance improve with the addition of at least one index on the column.

  • B. Every column that participates in a query should have an index.

  • C. There is a limit of 32 indexes on a table.

  • D. There is a limit of 32 columns in an index.

  • E. Columns that are often queried as part of a WHERE clause are good candidates for an index.

A6:

Answers D and E are correct. Columns that are in a WHERE clause are good candidates for indexes because they are limiting factors in queries, and there is a hard limit in Oracle that an index can have only 32 participating columns. Answer A is incorrect; indexes don't help insert, update, and delete performance. Answer B is incorrect; any column can participate in a query, but not every column should have an index. Answer C is incorrect; there is no limit on the number of indexes on a table.

7:

You need to determine the names and types of indexes as well as the owners of those indexes in the database. In which data dictionary view would you find this information?

  • A. DBA_INDEXES

  • B. DBA_IND_COLUMNS

  • C. V$INDEXES

  • D. DBA_IND_EXPRESSIONS

A7:

Answer A is correct; DBA_INDEXES provides the needed information. Answer B is incorrect; DBA_IND_COLUMNS does not contain the index type. Answer C is incorrect; V$INDEXES view does not exist. Answer D is incorrect; DBA_IND_EXPRESSIONS does not include the type of index and only tells you about function-based indexes.

8:

Which two statements are true about rebuilding indexes? [choose two]

  • A. The resulting index contains all the deleted entries from the original index.

  • B. The new index is built using the table data as its source.

  • C. The new index is built using the existing index data as its data source.

  • D. Queries cannot continue using the existing index until the new index is built.

  • E. During the online rebuild, Oracle requires that there be sufficient space for two copies of the indexes to exist in their respective tablespaces.

A8:

Answers C and E are correct; the index is built off the data in the existing indexes, and sufficient space needs to exist for two copies of the indexes for the duration of the rebuild. Answer A is incorrect; the new index will not include the deleted entries. Answer B is incorrect; the new index is built from the old index not from the table data. Answer D is incorrect; queries can continue throughout the rebuild if the rebuild is an online rebuild.

9:

Which of the following statements is true about bitmap indexes?

  • A. They are useful when a column contains few unique values that are changed frequently.

  • B. They are useful when a column contains few unique values that change infrequently.

  • C. They are useful when a column contains many unique values that change frequently.

  • D. They are useful when a column contains many unique values that change infrequently.

A9:

Answer B is correct; bitmap indexes are primarily useful when a column contains few unique values (brand name of sodas, genders, or makes of automobiles), and those values rarely change. All the others are conditions that would imply that bitmap indexes would not be an optimum choice.

10:

Which of the following is not a view that would provide information on indexes?

  • A. DBA_INDEXES

  • B. USER_IND_COLUMNS

  • C. ALL_IND_COLUMNS

  • D. V$INDEXES

A10:

Answer D is correct; the only view in the list that would not provide information on indexes in the database would be V$INDEXES, and that is because it is not a valid data dictionary view.


Chapter 14. Maintaining Data Integrity

Terms you'll need to understand:

  • DISABLE NOVALIDATE

  • DISABLE VALIDATE

  • ENABLE NOVALIDATE

  • ENABLE VALIDATE

Concepts you'll need to master:

  • Implement data integrity constraints.

  • Maintain data integrity constraints.

  • Obtain constraint information from the data dictionary.

Data integrity generally refers to the validity of data. Data integrity can be compromised in many different ways. Errors can be introduced when the data is entered or whenever the data is transmitted from one computer to another. Integrity can be compromised by software bugs, viruses, hardware malfunctions, or disk crashes. The introduction of invalid data can occur whenever a certain set of circumstances come together to create just the right conditions that would allow for the inaccuracies; and the inaccuracies might even mean that there are more copies of a given piece of information (such as a receipt or an invoice) than there should be at any given time.

This chapter deals with the manner in which Oracle enables you to avoid these inaccuracies. The first section defines what is meant technologically by data integrity with respect to Oracle databases and instances.


Defining Data Integrity

With respect to Oracle, data integrity often means that the data in the database consistently adheres to the business rules of the organization in question. The means by which this data remains consistent can be through application code, through the use of database triggers, and through declarative integrity constraints.

How any given business maps the business rules to these methods for designing in integrity is, usually, a combined decision made by the database administrator advising the designer. The administrator is primarily concerned with the implementation methods chosen by the designer and with balancing performance needs against the integrity requirements and the chosen method of implementation.

Application Code

Application code can either be implemented as stored procedures within the database or as applications running on the client or outside the database on the server.

Database Triggers

It was suggested to me by one of the people from whom I took an Oracle University class in Minnesota that, from a database administrator's perspective, "a trigger's a wonderful thing." At the time, we thought that he watched just a little too much Winnie the Pooh, but the sentiment has stayed with me.

Database triggers are PL/SQL programs whose executions are entirely event driven (such as on insert or after update or on error). Triggers can be enabled or disabled. That is to say, they can either be allowed to execute whenever the "triggering" event occurs, or they can be disallowed from occurring at all. Triggers are typically created to enforce complex business rules that cannot be defined as an integrity constraint.

Triggers are not a part of the Oracle 9i Fundamentals I exam, so they will not be explored in depth in this chapter. You should, however, be aware that they are a way to ensure integrity in the database.

Integrity Constraints

Integrity constraints are usually the preferred mechanism for the enforcement of business rules because they provide performance improvements, are easily declared and modified, and do not require extensive and complex coding. They tend to centralize the rules while allowing for flexibility and also have the advantage of being fully documented in the data dictionary.

A rule can be defined on a column or a set of columns in a single table that references (or matches) values in a related table. Referential integrity can also include rules that restrict the type of data manipulation allowed on the reference column values and how actions on those values affect the actions on dependent tables.

You can restrict, or disallow, the updating or deletion of referenced data so that you don't strand records in one table when the referencing data is deleted. You can set a column to either NULL or a default value when referenced data is updated or deleted. You can force updates or deletes to cascade to associated dependent data whenever the referenced data is updated or deleted. Or you can opt for no action to be allowed, meaning that updates or deletion on the referenced (parent) data be completely disallowed if child data exists. This differs from restricting because restriction is checked at the end of a statement or transaction. No action is the default action.

Table 14.1 lists the types of constraints available in Oracle and provides a description of those constraints.

Table 14.1. Constraints with Definition

Constraint

Description

Check

Specifies that a condition exists that every row in the table must satisfy.

Foreign key

Designates that a column or a combination of columns is a foreign key in a referential integrity constraint. Foreign keys can use the DELETE CASCADE rules that cause the deletion of all dependent rows when the referenced row is deleted. It can use the SET NULL rule so that information in the child table is retained when the parent information is updated or deleted but is no longer tied to a parent row. Finally, again by default, Oracle disallows the updating or deleting of the parent (referenced) information.

Not NULL

Specifies that a column cannot contain a null value. By definition, all columns in a table allow NULLs to exist. NULL is not the same as spaces; NULL is not the same as 0. It is the absence of data. A Not NULL constraint requires that a column of a table must not be allowed to contain NULL values.

Primary key

Designates that a column or a combination of columns is the given table's primary key. This designation carries with it an automatic index. A table can have at most one primary key; however, no table has to have a primary key. Any column included in a primary key cannot contain any NULL values.

Unique

Designates that a column or a combination of columns specifies the way that the entire row becomes guaranteed unique. This is nearly a primary key constraint, but it allows NULLs (NULL values are never equal to anything, not even another NULL; therefore, a column full of NULLs is by definition unique), and it does not carry an implicit index.

Foreign key constraints between two columns either in the same table or in different tables must be defined on columns with the exact same data type and size. The column names, however, do not have to match.

There are distinct advantages to using constraints over application code or triggers. Constraints enforce applicable business rules in code in the database rather than in the application logic. This means that any time the business rules change, the change can be made centrally to the database, and no one has to worry about those changes being missed in one of the application programs. Definition and declaration of constraints occurs by use of a simple SQL statement. Alteration requires no complex additional programming logic. Finally, the performance of placing the business rule in the constraints is at worst similar to the cost of executing a SQL statement that would evaluate that same logic. Using constraints also ensures that business rules are always enforced, no matter what method is used to modify the data.

Constraint States

Integrity constraints can either be enabled (ENABLE) or disabled (DISABLE). If a constraint is enabled, just as if a trigger is enabled, data is checked when it is being entered or updated, and data that does not conform to the given constraint's rule is prevented from being entered. If the constraint is disabled, any data entered in the database will be entered even if that data does not comply with the constraint rule.

An integrity constraint can be in any one of the following states:

  • DISABLE NOVALIDATE means that the constraint is not checked. Data in the table and any new data are entered and updated, and none of the data may any longer conform to the rules defined by the constraint. DISABLE implies NOVALIDATE unless VALIDATE is specified.

  • DISABLE VALIDATE means that the constraint is not active but also that no modification can take place in the constrained columns, and any indexes that were involved with the constraint are dropped.

  • ENABLE NOVALIDATE means that the constraint allows new data to be entered as long as that data meets the constrained condition but also that the data that is in the table does not have to meet those conditions. This is often a useful state in data warehousing where valid OLTP data is being uploaded.

  • ENABLE VALIDATE means that no row that violates the constraint can be entered into the table, and no row that violates the constraint exists in the table. If the constraint was in the ENABLE NOVALIDATE or the disabled state and then the constraint was altered to the ENABLE VALIDATE state, rows that weren't validated need to be altered or deleted if they don't conform when the validation is reenabled. ENABLE implies VALIDATE unless NOVALIDATE is specified.

Whenever a unique or primary key constraint moves from the DISABLE state to the ENABLE state and there is no existing index, a unique index gets created automatically. The converse is also true; whenever a primary key moves from an ENABLE state to the DISABLE state, the index is dropped.

Whenever any constraint moves from the NOVALIDATE to VALIDATE state, all data must consequently be checked. Moving from VALIDATE to NOVALIDATE, naturally, ignores the fact that the data has ever been checked for validity. This means that if you move from VALIDATE to NOVALIDATE and immediately back to VALIDATE without entering or changing any data, every entry has to be rechecked.

Constraint Checking

Your database can either check constraints to ensure data validity during the transaction, or defer the checking until the end of the transaction.

Nondeferred constraints are considered to be immediate constraints and are enforced at the end of each and every DML statement. Constraint violations in this case cause the statement to be rolled back immediately. If the constraint causes an action such as DELETE CASCADE, the action is taken as an immediate part of the statement that caused it. Constraints defined as nondeferrable cannot later be modified to be enforced at the end of a transaction rather than at the end of every DML.

Deferred constraints are checked only at the end of a transaction when that transaction is committed. At that time, if any constraint violations are detected, the entire transaction is rolled back. Deferred constraints are particularly useful when you are inserting both the parent and child rows in a foreign key relationship at the same time, as in an order entry system where the order and the items on that order are being entered at the same time.

Constraints can be defined as deferred and have either of the following characteristics:

  • INITIALLY IMMEDIATE means that by default the constraint should behave as if it were an immediate constraint and any other behavior needs to be set otherwise.

  • INITIALLY DEFERRED means that by default the constraint should be enforced only at the end of the transaction.

You can either use the SET CONSTRAINTS statement to make a constraint either DEFERRED or IMMEDIATE, or you can use the ALTER SESSION statement to make alterations using the SET CONSTRAINTS to DEFERRED or to IMMEDIATE.

The SET CONSTRAINTS statement makes constraints either DEFERRED or IMMEDIATE for a particular transaction and can either be used to set a single constraint or a list of constraints. SET CONSTRAINT lasts for the duration of the transaction, or until another SET CONSTRAINTS statement resets the mode. SET CONSTRAINTS is not allowed inside triggers. An example of the generic version of this statement follows:

SET CONSTRAINT | CONSTRAINTS {constraint name|constraint list| ALL} {IMMEDIATE|DEFERRED}

The ALTER SESSION SET CONSTRAINTS command implies setting all constraints, and no list of constraints can be specified. The statement applies to the current session only. An example of the generic ALTER SESSION command follows:

ALTER SESSION SET CONSTRAINTS = {IMMEDIATE|DEFERRED|DEFAULT}

Enforcing Primary and Unique Key Constraints

Primary keys and unique keys are enforced using indexes. You can control both the location of the index and the type of index used for enforcing these constraints. Oracle uses the following process to determine how to enforce the constraints:

  • If the constraint is disabled, no indexes are needed.

  • If the constraint is enabled and the columns in the constraint form the leading part of the index, the index is used to enforce the constraint whether the index itself was created as unique or nonunique.

  • If the constraint is enabled and there is no index that uses the constraint columns as the leading part of the index, an index with the same name as the constraint is created using the following rules:

    • If the key is deferrable, a nonunique index on the key columns is built.

    • If the key is nondeferrable, a unique index is created.

  • If an index is available to be used and the constraint is nondeferred, Oracle uses the existing index.

  • If an index is available to be used, the constraint is deferrable, and the index is nonunique, Oracle uses the existing index.

Guidelines for Using Constraints

It is necessary to take many things into consideration when determining what constraints to define on a table.

When primary keys and unique constraints are created, it is important to remember that these imply indexes even if you don't specify the indexes, and the indexes should be deliberately built and built in a tablespace separate from the one that houses the table. This is accomplished either using the USING INDEX clause or by first creating the table, then creating the index, and then altering the table to add or enable the constraint.

If you are anticipating a large number of bulk loads on the table, nonunique indexes would be preferred over unique indexes. Further, if you are doing bulk loads, it is typically preferable to disable the constraints, perform the load, and then reenable the constraints. If a unique index is used for enforcing a primary key or unique constraint, this index needs to be dropped when the constraint is disabled.

For self-referencing foreign keys (keys that join tables to themselves), you should define or enable foreign keys only after the initial load and defer constraint checking. Defining the constraints as deferrable is the most useful method when the table will be used as the target for frequent bulk loads.

You are now ready to define and implement data integrity constraints. The following section guides you through the considerations and implementation of these constraints.


Implementing Data Integrity Constraints

Data integrity constraints can take on different forms. These constraints can provide you and your users with a level of security in the viability of the data that would likely not be available without their use.

Foreign Keys

Whenever you are creating relationships between two tables that have an implied many-to-one relationship (employee-dependent, manager-employee, order-item), foreign key relationships are usually the manner used to ensure that the relationship remains intact. You will need to consider, both from a technical perspective and from a business rules perspective, several factors when deciding how to maintain the tables involved in the relationship.

DDL on Parent Table

Any time that DDL is done on the parent table, considerations concerning the constraints have to be taken into account.

Whenever you decide that you need to drop a parent table, you need to drop the foreign key constraint before you can complete the parent table drop. This can be accomplished in a single statement:

DROP TABLE tablename CASCADE CONSTRAINTS

Whenever you decide that you need to truncate the parent table, you need to either drop the foreign key constraint or at least disable it.

If you are going to drop a tablespace that contains the parent table, the foreign key constraint must be dropped before you can drop the tablespace. Again, this can be accomplished in a single statement:

DROP TABLESPACE tablespace_name INCLUDING CONTENTS CASCADE CONSTRAINTS

If you don't use DROP with the CASCADE CONSTRAINTS option, whenever rows are deleted from the parent table, Oracle locks the child table or tables that have foreign key relationship to the parent to ensure that there are no rows remaining in the child table that would have corresponded to the parent table rows being deleted. This ensures that you don't have garbage in your databasefor example, ordered items with no order to associate them to, or dependents with no employee to whom they are tied. Updates to the parent's key are permitted only when no child rows are tied to the old value. If no index exists on the foreign key in the child table, Oracle locks the entire child table to prevent any changes that would affect referential integrity. If there is an index on the foreign key, Oracle locks only the index entries, thereby avoiding more restrictive locks on the entire child table.

If you determine that both tables need to be updated concurrently but from different transactions, it is best to create an index on the foreign key columns.

Whenever data is inserted into the child table (the table with the foreign key constraint) or whenever the foreign key column is updated, Oracle checks the index on the parent table that is being used for enforcing the referenced key. It is, therefore, critical that the tablespace of the parent table's index, but not necessarily the tablespace containing the parent table, be online whenever inserts or updates are being done on the child table.

Defining Constraints at Table Creation Time

Constraints can be defined either when a table is being created or by altering the table to create it. The constraint clause in the CREATE TABLE or the ALTER TABLE statement is used to define the constraint on the table. Certain privileges must be in place to define an integrity constraint on a given set of tables. Either the user defining the constraint needs to own the parent table (it must be in that user's schema) or the user must have REFERENCES privileges on the columns of the referenced key in the parent table.

The generic format for the CREATE TABLE with CONSTRAINT included follows:

CREATE TABLE table_name (
Column_name column_datatype [CONSTRAINT constraint_name]
{[NOT] NULL
|UNIQUE [USING INDEX index_clause]
|PRIMARY KEY [USING INDEX index_clause]
|REFERENCES [schema.]table (column) [ON DELETE CASCADE]
|CHECK (conditions)}
[NOT DEFERRABLE| DEFERRABLE [INITIALLY {IMMEDIATE|DEFERRED}]]
[DISABLE|ENABLE [VALIDATE| NOVALIDATE]])

The following list explains these terms and commands:

  • CONSTRAINT identifies the integrity constraint by the name supplied, and that information is stored in the data dictionary.

  • USING INDEX means that the parameters defined in the clause should be used for the index that Oracle uses to enforce the unique or primary key constraint. The name of the index is the same as the name of the constraint.

  • DEFERRABLE indicates that the constraint checking can be deferred until the end of the transaction by using the SET CONSTRAINT command.

  • NOT DEFERRABLE indicates that the constraint is checked at the end of every DML statement and cannot be deferred by sessions or transactions. This is the default.

  • INITIALLY IMMEDIATE says that, the constraint is checked at the end of every DML statement. If no INITIALLY clause is specified, INITIALLY IMMEDIATE is implied by default.

  • INITIALLY DEFERRED says that the constraint is DEFERRABLE and that the constraint will only be checked, by default, at the end of every transaction.

  • DISABLE disables the integrity constraint, and Oracle will not enforce it until it is ENABLED.

It is considered good practice to adopt a standard naming convention for constraints; this is particularly true for check constraints because the same constraint can be created several times with different names.

Table Constraints

A table constraint is a constraint that is a part of the table definition and is considered to be a part of the table rather than simply a consideration on the column. It can define any type of constraint except a NOT NULL constraint and takes the previously defined format.

Table constraints are needed when a constraint names two or more columns or when a table is altered to add any constraint other than the NOT NULL constraint.

You can define the NOT NULL constraint after creating the table as follows:

ALTER TABLE table_name MODIFY column CONSTRAINT constraint_name NOT NULL;

You can define other constraints after table creation as in the following example:

ALTER TABLE items ADD CONSTRAINT orders_items_fk FOREIGN KEY (order_no)
REFERENCES orders (order_no)
DEFERRABLE INITIALLY DEFERRED;

Now that we have defined constraints on the table and on individual columns (NOT NULL), we need to turn our attention to addressing the maintenance of the constraints.


Maintaining Integrity Constraints

After integrity constraints have been created, it often becomes necessary to change their state, or to otherwise manipulate them. This section covers those functions.

Enabling Constraints

A disabled constraint can be enabled in either of two ways: ENABLE NOVALIDATE or ENABLE VALIDATE.

ENABLE NOVALIDATE

For primary keys and unique constraints that already have existing indexes built on them, enabling a constraint NOVALIDATE is faster than enabling it VALIDATE because existing data is not checked for constraint violation. If this option is used, no locks are required on the table, and the option is therefore highly appropriate for OLTP environments where a lot of DML activity is taking place on the table.

The following ALTER statement enables the constraint named constraint_name with the NOVALIDATE option:

ALTER TABLE tablename
ENABLE NOVALIDATE CONSTRAINT constraint_name |PRIMARY KEY |UNIQUE (column, column...)
[USING INDEX index clause]

USING INDEX clauses are applicable only for PRIMARY KEY or UNIQUE CONSTRAINTS that have been created as deferrable, and either the constraints were created disabled or the constraints were disabled and the index dropped.

If the index needs to be created using the ENABLE CONSTRAINT method, NOVALIDATE does not offer any significant benefit over VALIDATE because Oracle locks the table to build the index.

ENABLE VALIDATE

ENABLE VALIDATE checks existing data in the table for constraint validation when the constraint is reenabled. When a constraint is enabled, VALIDATE is the default. When a constraint that is disabled is ENABLED VALIDATE, it has the following effect:

  • The table is locked and changes to the table and to data within the table are prevented until validation has completed.

  • Oracle creates an index if one does not already exist. A unique index is created while enabling a primary key or a unique constraint that is nondeferrable, and a nonunique index is created of deferrable primary keys or unique constraints.

If ENABLE VALIDATE is executed when a constraint is enforced, it does not require any locks be acquired on the table during validation because the enforcement guarantees that no violations will be introduced during the validation. This has several advantages:

  • All constraints are enabled concurrently.

  • Each constraint is internally parallelized, allowing for performance gains.

  • Concurrent activity on the table is permitted.

VALIDATE is the default when enabling constraints and therefore does not need to be specified when enabling a disabled constraint.

If data in a table violates the constraint, the statement is rolled back, and the constraint remains in a disabled state.

It is important to remember that if ENABLE VALIDATE finds data that violates the constraint, the statement is rolled back and the constraint remains disabled. This may be included in a trick question.

Using the EXCEPTIONS Table

You create the EXCEPTIONS table by running the utlexcpt.sql script in the %ORACLE_HOME%\rdbms\admin directory on Windows or the $ORACLE_HOME /rdbms/admin directory on Unix. You can then execute the ALTER TABLE statement with the EXCEPTIONS option, and rows that violate constraints will have information included in the EXCEPTIONS table that will allow you to easily find the offending row or rows and rectify the data that has caused the exceptions to the constraints. After you have found and fixed the errant data, you can re-execute the ALTER TABLE statement to enable constraints.

The EXCEPTIONS table has four columns, ROW_ID, OWNER, TABLE_NAME, and CONSTRAINT. With this information, you can access the row directly with the ROWID (recall this uniquely identifies a row within the database) in the OWNER.TABLE table and determine what CONSTRAINT was violated so that you can more easily fix the problems.

The following ALTER statement enables the addresses_lastname_pk constraints and directs all exceptions into the exceptions table created by the utlexcpt.sql script:

ALTER TABLE addresses
ENABLE VALIDATE CONSTRAINT addresses_lastname_pk
EXCEPTIONS INTO SYSTEM.EXCEPTIONS;

If the EXCEPTIONS table does not belong to the user running the ALTER TABLE statement, it needs to be qualified with the owner. You can centralize the table in the SYSTEM schema and grant SELECT, INSERT, UPDATE, and DELETE on the table to everyone. To do this, create a PUBLIC SYNONYM, thereby eliminating the need to dereference the table name with the owning schema name. Not only will this allow users to more easily code programs to use the EXCEPTIONS table, it will also allow you to more elegantly maintain the system.

After you, or the user, have dealt with all exceptions, you can truncate the EXCEPTIONS table, and the constraint can be reenabled.

Again, it is simple to find information on constraints in the database by going to the data dictionary. The following section provides information on accessing that information.


Constraint Information in the Data Dictionary

If you need to find information on the data dictionary concerning constraints, you have only two general views to access to find that information:

  • DBA_CONS_COLUMNS (ALL_CONS_COLUMNS and USER_CONS_COLUMNS) shows columns affected by each constraint and all the constraints that affect columns. From this view, you can find the constraint name, the table name, the column name, and the position of the column in the constraint (for multicolumn constraints).

  • DBA_CONSTRAINTS (ALL_CONSTRAINTS and USER_CONSTRAINTS) defines the constraints defined within the database, the constraint type, deletion rule (cascade or not), the deferrable and deferred statuses, and other pertinent information.


Exam Prep Questions

1:

What command would you use to disable a constraint?

  • A. ALTER TABLE

  • B. DROP CONSTRAINT

  • C. ALTER SESSION

  • D. DELETE CONSTRAINT

A1:

Answer A is correct; you would disable the constraint with the ALTER TABLE command. Answer B is incorrect because the DROP CONSTRAINT clause to the ALTER TABLE statement would not disable the constraint but would delete it. Answer C is incorrect; ALTER SESSION allows you to change validation methods (DEFERRED, IMMEDIATE, VALIDATE, or NO VALIDATE) but does not allow you to disable it. Answer D is incorrect; DELETE CONSTRAINT isn't a valid command or clause to a command.

2:

Which keywords would you use to allow exiting data in a table to violate a constraint while causing the constraint to validate new data?

  • A. DISABLE NOVALIDATE

  • B. DISABLE VALIDATE

  • C. ENABLE NOVALIDATE

  • D. ENABLE VALIDATE

A2:

Answer C is correct; you would use the ENABLE NOVALIDATE command to enable constraint checking on new data entering the table but to also ignore any inconsistencies that would already exist in the tables. Answer A is incorrect; DISABLE NOVALIDATE means that neither the existing data nor the new data are validated. Answer B is incorrect because the constraint is disabled, but also because no alterations to data in the constrained columns can occur, including inserts, updates, or deletes. Answer D is incorrect because, although ENABLE VALIDATE will validate all new data entering the table, it will also validate all the data that already exists in the table.

3:

In what cases does Oracle automatically create indexes to support the constraints? [check all that apply]

  • A. NOT NULL

  • B. CHECK

  • C. PRIMARY KEY

  • D. FOREIGN KEY

  • E. UNIQUE

A3:

Answers C and E are correct. Oracle creates indexes to support primary keys and unique constraints. Answer A is incorrect; NOT NULL constraints are not supported by an index. Answer B is incorrect; CHECK constraints are used to make sure that data that falls within a range is inserted into a column and are not supported by an Oracle-generated index. Answer D is incorrect. It is often a good idea to index foreign key columns; however, these indexes are not created by Oracle.

4:

What are the two methods that can be used to create an integrity constraint on a user table? [Select two]

  • A. ALTER TABLE ENABLE CONSTRAINT

  • B. ALTER TABLE ADD CONSTRAINT

  • C. CREATE TABLE

  • D. CREATE DATABASE

  • E. CREATE UNIQUE INDEX

A4:

Answers B and C are correct; you can alter the table and add the constraint, or you can create the constraint when you create the table. Answer A is incorrect; ENABLE CONSTRAINT allows you to reenable a deferred and disabled constraint but not create a constraint. Answer D is incorrect; tables and therefore constraints are not created on user tables at database creation time. Answer E is incorrect, you can create a unique index on a constrained set of columns, or you can attempt to enforce integrity with a unique index, but it does not create a constraint.

5:

Which of the following choices identify a command that you might use if you want to disable the primary key integrity constraint?

  • A. ALTER TABLE

  • B. ALTER CONSTRAINT

  • C. ALTER INDEX

  • D. ALTER SYSTEM

A5:

Answer A is correct; you would alter the table to disable the primary key constraint. Answer B is incorrect; ALTER CONSTRAINT is an invalid command. Answer C is incorrect; altering the index won't disable the constraint. Answer D is incorrect; you can't disable the constraint by altering the system.

6:

You want to create a table into which information will be placed that will direct people to rows that violate integrity constraints. Which Oracle supplied script will accomplish this?

  • A. utlrp.sql

  • B. utlexcpt.sql

  • C. EXCEPTIONS.sql

  • D. catalog.sql

A6:

Answer B is correct; utlexcpt.sql creates the EXCEPTIONS table. Answer A is incorrect; utlrp.sql recompiles invalid objects in the database. Answer C is incorrect; EXCEPTIONS is the name of the table, not the name of the script to create it. Answer D is incorrect; catalog.sql creates the data dictionary tables and views.

7:

When attempting to reenable the primary key constraint on a table after a bulk data load, the DBA receives the following error:

ORA-02299: cannot enable <primary key name> - duplicate keys found.

Where might the DBA be able to find the rows that are causing the issues?

  • A. DBA_CONS_COLUMNS

  • B. DBA_CONSTRAINTS

  • C. DBA_PRIMARY_KEY_COLUMNS

  • D. EXCEPTIONS

A7:

Answer D is correct; the EXCEPTIONS table will point the DBA at the rows that are in error and the constraint that has been violated. Answer A is incorrect; from the DBA_CONS_COLUMNS view, you can find the constraints and their columns. Answer B is incorrect; from the DBA_CONSTRAINTS, you can find the names and types of constraints but not what rows violate the constraints. Answer C is incorrect; it is not a valid data dictionary view.

8:

You notice that the system-generated indexes associated with the integrity constraints in the database have been defined as nonunique. What can you infer from this?

  • A. The constraint is a nondeferrable primary key.

  • B. Something is wrong with the database.

  • C. An error caused a data load to abort.

  • D. The index was built on a deferrable unique constraint.

A8:

Answer D is correct; the constraint was unique but deferrable. Answer A is incorrect; nondeferrable primary keys would create a unique index. Answer B is incorrect; this is not a way to determine whether something is wrong with the database. Answer C is incorrect; an aborted load would not cause an index to be either unique or nonunique.

9:

Which data dictionary view contains a listing of all the columns that are a part of a data integrity constraint?

  • A. DBA_CONSTRAINT

  • B. DBA_CONS_COLUMNS

  • C. V$CONSTRAINTS

  • D. DBA_IND_COLS

A9:

Answer B is correct; DBA_CONS_COLUMNS provides you with the columns involved as a part of an integrity constraint. Answer A is incorrect; DBA_CONSTRAINTS gives you the constraint name but not the columns in the constraint. Answer C is incorrect; it is not a data dictionary view. Answer D is incorrect. It tells you columns in an index, not columns in a constraint; they can be different.

10:

At what point in a transaction will a deferred constraint be checked?

  • A. At the beginning of every DML statement

  • B. At the end of every DML statement

  • C. Whenever a trigger fires

  • D. Whenever the database checkpoints

  • E. At the end of the transaction, when it commits

A10:

Answer E is correct; the deferred constraint will commit whenever the transaction finishes and commits. Answer A is incorrect; constraints are not checked when a DML statement begins. Answer B is incorrect; nondeferred, or immediate, constraints are checked when the DML statement finishes. Answer C is incorrect; the point of integrity constraints is that they are not reliant on a trigger's code or on a trigger firing. Answer D is incorrect; checkpoints and integrity checking are independent and unrelated processes.


Chapter 15. Managing Users

Terms you'll need to understand:

  • CREATE USER

  • ALTER USER

  • OS_AUTHENT_PREFIX

  • EXTERNALLY

  • QUOTA

  • PASSWORD EXPIRE

  • ACCOUNT LOCK

  • ACCOUNT UNLOCK

  • REMOTE_OS_AUTHENT

Concepts you'll need to master:

  • Create new database users.

  • Alter database users.

  • Drop database users.

  • Monitor information about existing users.

Your database will be of little use if you are the only one who can log in to it. It will be highly unstable and unsecure if you allow everyone to log in as SYS or SYSTEM. Therefore, one of the other functions that will occasionally occupy your time is creating, deleting, or managing users. This chapter provides valuable insight into the care and feeding of your users from the standpoint of the database.

Naturally, the safest database is one that no users ever have a means of connecting to. However, with no users, there is little reason for a database to exist. The database administrator (you) defines the names of the users who are permitted to access the database, and a security domain defines the settings that apply to each user. This chapter covers how to create, alter, delete, and monitor users in your database.

Because you can do little with a user until you actually have at least one user defined to your database, we will look at creating users first.


Creating New Users

Before you actually create a user, you need to determine how you intend for that user to be authenticated in order to connect to the database. The primary means of authenticating to the database are operating system authentication and data dictionary authentication.

You can define a user such that the database is responsible for not only the accurate identification of users but also their authentication. This kind of authentication is called database authentication.

You could, alternatively, define users in such a way that authentication is performed by the operating system, also known as external authentication.

Database Authentication

Choosing database authentication for any given user means that administration for the user account, including all authentication of that user is performed entirely by Oracle. This means that you have to specify a password for a user whenever you create or alter that user. Users have the ability to change their passwords at any time, and those passwords are stored, in an encrypted format, in the data dictionary. Each password must be made up of single byte characters, even if the database uses a multibyte character set (see Chapter 7, "Globalization Support," which discusses globalizations and database character sets).

Oracle recommends that you always encode usernames and passwords using ASCII or EBCDIC characters (depending entirely on your platform). This allows usernames and passwords to function regardless of any database character set conversions that you do. This is important to remember because no username or password conversions are done during migration to a new database character set.

To facilitate enhanced security for database authentication, Oracle recommends that you judiciously manage passwords. This includes account locking, password aging, password expiration, password history, and password complexity verification.

The following statement creates a user that is database authenticated:

CREATE USER awells IDENTIFIED BY author;

This means that any time that user awells wants to connect to the database, he must specify the password author to connect.

There are several advantages to using database authentication:

  • User accounts and all associated authentication are handled by the database. There is no need to rely on anything outside the database.

  • Oracle provides highly secure and strong password management features that can enhance security when using database authentication that is not always available in operating system authentication.

  • Database authentication is much easier to manage, especially when there is a small user community.

External Authentication

Whenever you choose external authentication for a user, that user's account is maintained by Oracle, but password administration and user authentication are performed by an external service, often outside the influence and control of the database administrator.

With external authentication, your database has to rely on the underlying operating system authentication as a means to restrict access to database accounts. No passwords are used as direct control for user login.

The following statement creates a user identified by Oracle and authenticated by the operating system:

CREATE USER awells IDENTIFIED EXTERNALLY;

In this case, the user, awells, has a database account authenticated by the operating system, and Oracle relies on the external login authentication to ensure that the user has access not only to the operating system but also to the database as a specific user.

Optionally, you can set the OS_AUTHENT_PREFIX parameter in the initialization file to specify the format of the prefix for usernames in the database. This parameter defaults to OPS$ to make Oracle 9i backward compatible with earlier releases. You can set the prefix to a NULL value as follows:

OS_AUTHENT_PREFIX=""

You can specify the prefix DWH for all data warehouse users as follows:

OS_AUTHENT_PREFIX="DWH"

Setting this parameter allows for added flexibility if desired. You can create a user who is authenticated either by password or by operating system if you specify the following command:

CREATE USER ops$awells IDENTIFIED BY password;

If the awells user were to log in to the database directly from the server running the database, she would not need to supply a password, but if that same user needed to connect from a remote client, she could do so by supplying the password.

By default, Oracle allows operating system authenticated logins only through secure connections. This means that, if you want to use operating system authentication, the user cannot connect to the database over Oracle Net or through a shared server configuration. This default restriction prevents users from being able to impersonate another operating system user over a network connection. You can set the initialization parameter REMOTE_OS_AUTHENT (which is by default set to FALSE) to trUE in the initialization parameter file and thereby allow the database to accept client operating system usernames received over a nonsecure connection to be used for account authentication.

External authentication offers its own advantages:

  • Users can connect to Oracle faster because they don't have to specify a separate database username and password.

  • All user entries in the database and operating system audit trails will correspond.

User Account Defaults

Many defaults can be associated with a user account. The following list provides many that are of particular interest:

  • Tablespace quotas control the amount of physical storage allotted to a user in the tablespaces in the database. Any user may have different quotas on several different tablespaces in the database.

  • Default tablespace defines the default location where segments will be created by the user. Segments will always be stored in this location unless the user explicitly specifies another tablespace at the segment creation time. It is important to remember that, if you don't specify a default tablespace for any user, the SYSTEM tablespace will become the default tablespace for that user.

  • Temporary tablespace defines the place where the user can allocate temporary extents if the given user requires a location to write sort data to disk. If there is a default temporary tablespace in the database, the parameter will override that default.

  • Account locking can be used to prevent a user from logging in to the database. This can either be set to occur automatically, or the database administrator can manually lock or unlock a user's account.

  • Resource limits can be placed on the use of certain resources (such as CPU time, logical I/O, and the number of allowable open sessions per user).

  • Direct privileges are used to maintain control over many of the actions that a user can perform.

  • Role privileges can be further granted to indirectly control the actions of a user.

More information on roles and privileges can be found in Chapter 17, "Managing Privileges," and Chapter 18, "Managing Roles."

Recall that a database schema is a named collection of objects (tables, indexes, views, clusters, stored procedures, and packages). A user is created, and at the same time a corresponding schema is created. A user can exist and a schema can exist without the existence of objects reliant on either one. A user can be associated with exactly one schema, and username and schema are often used interchangeably.

When a user is created, you need to identify the tablespaces in which the user will need to store objects, decide on quotas for each of those tablespaces, and assign both a default tablespace and a temporary tablespace to the user. After you have made those decisions, create the user and grant that user the appropriate privileges and roles.

The following is an example of a CREATE USER script that sets most of the defaults for the user:

CREATE USER awells IDENTIFIED BY password
DEFAULT TABLESPACE userdata
TEMPORARY TABLESPACE usertemp
QUOTA 50M ON userdata
PASSWORD EXPIRE;

Generically, the command looks like the following:

CREATE USER username
IDENTIFIED {BY password |EXTERNALLY}
[DEFAULT TABLESPACE tablespace_name]
[TEMPORARY TABLESPACE temporary_tablespace_name]
[QUOTA {integer K|M |UNLIMITED} ON tablespace_name
QUOTA {integer K|M |UNLIMITED} ON tablespace_name
QUOTA {integer K|M |UNLIMITED} ON tablespace_name
...]
[PASSWORD EXPIRE]
[ACCOUNT {LOCK | UNLOCK }]
[PROFILE {profile | DEFAULT }]

With the following descriptions:

  • Username is the name of the new user.

  • BY password signifies that the user will be authenticated by the database and will have to supply the given password to log in.

  • EXTERNALLY signifies that the user is operating system authenticated.

  • DEFAULT TABLESPACE specifies the user's default tablespace.

  • TEMPORARY TABLESPACE specifies the user's temporary tablespace.

  • QUOTA specifies the maximum allowed space for the user for objects in the specified tablespace and can either be specified in integer values of kilobytes or megabytes or can be set as UNLIMITED. By default, no user has any quota on any tablespace.

  • PASSWORD EXPIRE forces the user to reset his password the first time that he attempts to log in to the database using SQL*Plus. This option is valid only for database authentication.

  • ACCOUNT LOCK/UNLOCK specifies that the user's account is either locked or unlocked; UNLOCK is the default.

  • PROFILE is often used to control resource usage and to specify the password control mechanism to be used for the given user.

The authentication method is mandatory.

If password expiration has been set, whenever the user logs in to the database with SQL*Plus, she receives the following message and is prompted to enter the new password:

ERROR:
ORA-28001: the account has expired
Changing password for <user>
Old password:
New password:
Retype new password:
Password changed
SQL>

Now that you have created a user, we will look at how that user can be altered.


Altering Users

A user, once created, can subsequently be altered. Any of the default settings provided by the CREATE USER command can be altered with the ALTER USER command.

It will often become necessary to modify a user's tablespace quota when tables owned by that user have seen unanticipated growth, when an application is enhanced and therefore requires additional tables or indexes that weren't taken into account originally, or when objects are reorganized and placed into different tablespaces.

The following command alters the awells user, removes all quota on userdata tablespace, gives unlimited space on awellsdata tablespace, and sets the default tablespace and the user's temporary tablespace:

ALTER USER awells
QUOTA 0 ON userdata
QUOTA UNLIMITED ON awellsdata
TEMPORARY TABLESPACE new_temp
DEFAULT TABLESPACE new_default;

When a schema owner's quota is set back to 0, the objects owned by that user still exist in the given tablespace, but no new space can be allocated to the objects. If the object's size changes due to deleting data or truncating tables, again no new space can be allocated. After the currently allocated extents have been filled, no new inserts can be put into those tables and/or indexes.

And finally, you can not only create and alter users but also, when it becomes necessary, you can drop the user.


Dropping Users

Any users, except for SYS and SYSTEM, can be dropped from the database as long as the user to be dropped is not actively logged on.

The following code drops the user as well as all the user's objects:

DROP USER username [CASCADE];

The CASCADE option drops all the objects in the schema before dropping the user and must be specified if the schema being dropped contains any objects.

If you need to learn about the users in your database, information can, naturally, be found in the data dictionary.


User Information in the Data Dictionary

Information about users can be found in the following two data dictionary views:

  • DBA_USERS lists all the users in the database and their database-related characteristics. ALL_USERS provides the username, user_id, and created columns, so is limited in its usefulness, and there is no user_users view.

  • Information on the tablespace quotas can be found by querying the DBA_TS_QUOTAS data dictionary view.


Exam Prep Questions

Use the following command and its output information to answer questions 1 and 2:

SELECT TABLESPACE_NAME, CONTENTS, FROM DBA_TABLESPACES

TABLESPACE_NAME | CONTENTS
SYSTEM | PERMANENT
MYDATA | PERMANENT
MYINDEXES | PERMANENT
UNDOTBS1 | UNDO
TEMP | TEMPORARY
USERS | PERMANENT

1:

Your database has the TEMP tablespace set as the database default temporary tablespace. If you run the following command, where will the user's temporary segments be built?

CREATE USER amandya IDENTIFIED BY squirrel;

  • A. SYSTEM

  • B. MYDATA

  • C. TEMP

  • D. UNDOTBS1

A1:

Answer C is correct. Based on the data returned by the query, the user's temporary segments will be located in the default temporary tablespace. Answer A is incorrect; if there were no temporary tablespace in the database, the user's temporary segments would be created in the SYSTEM tablespace, but because there is a temporary tablespace, that is where they are created. Answer B is incorrect; temporary segments are not usually created in a permanent tablespace. Answer D is incorrect; temporary segments are never located in undo tablespaces.

2:

Where will the newly created amandya user's data be stored?

  • A. UNDOTBS1

  • B. MYDATA

  • C. USERS

  • D. There is no way to tell for sure.

A2:

Answer D is correct; there is no way, based on the given information, to determine where the user's data will be created by default. One could infer that it might likely be the SYSTEM tablespace, but there is no way to tell for sure based just on the information provided. Answer A is incorrect; no user data is stored in the undo tablespace. Answers B and C are potential places, but without further information there is no way to be sure.

3:

You are working for an extremely security conscious company, and no one is permitted to know anyone else's password, not even the administrator. Adam has just joined your organization and needs to be given access to the database. Which of the following clauses will allow you to create the userid for Adam in the database and still provide the level of security necessary?

  • A. CREATE USER

  • B. IDENTIFIED BY nutsy

  • C. QUOTA

  • D. PASSWORD EXPIRE

  • E. ACCOUNT LOCK

A3:

Answer D is correct; PASSWORD EXPIRE requires that the new user change his password as soon as he logs in the first time with SQL*Plus. Answer A is incorrect; there are no security or password ramifications tied directly to the CREATE USER clause. Answer B is incorrect; the IDENTIFIED BY clause sets the initial password that you now know and signifies that the user is database authenticated. Answer C is incorrect; the QUOTA clause sets the amount of space allowed to be used by the new userid. Answer E is incorrect; if the account is in the lock status, the user will not be able to log in to the database regardless of what his password is.

4:

User Larry has decided to take on a new job opportunity in a new organization. His manager has requested that you remove his userid from the database. Upon analysis of the database, you determine that user Larry has 75 tables in the MYDATA tablespace and 82 indexes in the MYINDEXES tablespace. Along with his data in these tablespaces, there exists several hundred megabytes of data for other users. What is the most expedient way to quickly remove Larry from your database without severely impacting other users?

  • A. DROP USER larry;

  • B. Move everyone else's tables and indexes into new tablespaces, drop the MYDATA and the MYINDEXES tablespaces, and then drop the Larry user.

  • C. Individually disable all constraints on Larry's tables and then drop each one individually. Then drop all the indexes individually and drop any other objects that Larry owned. Then drop the user Larry.

  • D. DROP USER larry CASCADE;

A4:

Answer D is correct; DROP USER...CASCADE is the most expedient way to drop the user because all the user's objects have to be dropped before the user can be dropped. Answer A is incorrect because we are told that the user has a significant number of tables, and there is no way to drop the user without dropping all the user's objects. Answer B could allow you to drop the user, but would impact all the users in the tablespaces and would take a considerable amount of time. Answer C would likewise work but again would take a considerable amount of time and research effort.

5:

User Lynn asked her boss, user Lonny, to change her password while she was out of town on vacation, but she did not give him her old password. What command would user Lonny use when logged in to the database as himself to change her password:

  • A. ALTER USER lynn IDENTIFIED BY newpassword

  • B. ALTER USER lynn IDENTIFIED EXTERNALLY

  • C. CREATE USER lynn identified by newpassword

  • D. None of the above

A5:

Answer D is correct; users can only alter the userid that they are logged in with or must have been deliberately granted ALTER ANY USER privilege or DBA role (none of these were indicated). Lonny didn't know Lynn's password, so he could not change her password. Answer A is incorrect because Lonny has no way to log in as Lynn and therefore cannot change her password. Answer B is incorrect; if Lynn has a password, it isn't likely that she is using OS authentication. Answer C is incorrect; Lonny would neither want nor would he be able to create a user called lynn because she already exists in the database.

6:

What is the name of the initialization parameter that you can set to allow users to use remote operating system authentication?

  • A. OS_AUTHENT_PREFIX

  • B. REMOTE_OS_USER

  • C. REMOTE_OS_AUTHENT

  • D. REMOTE_OS_AUTHENTICATION

A6:

Answer C is correct. You can set REMOTE_OS_AUTHENT to TRUE to enable users to use remote operating system authentication. Answer A is incorrect; it sets a default prefix for all OS authenticated userids. Answer B is incorrect; there is no such parameter. Answer D is incorrect for the same reason; however, don't be fooled because it looks more accurate than C.

7:

If the DBA is using OS authentication, which of the following clauses will cause an error?

  • A. CREATE USER ops$freeman

  • B. IDENTIFIED EXTERNALLY

  • C. DEFAULT TABLESPACE mydata

  • D. There are no errors.

A7:

Answer D is correct; there are no errors in this statement.

8:

Which of the following aspects of a user account can an individual user change?

  • A. DEFAULT TABLESPACE

  • B. TEMPORARY TABLESPACE

  • C. IDENTIFIED BY

  • D. QUOTA

A8:

Answer C is correct; the only aspect of a user's account that he has any direct control over is the password, which is changed with the IDENTIFIED BY clause.

9:

User joy is created in the database. She is database authenticated, but no defaults have been set. When she attempts to create her first table, where will it be created?

  • A. Temp tablespace

  • B. SYSTEM tablespace

  • C. Her default tablespace

  • D. No table will be created.

A9:

Answer D is correct; no table will be created because no default quota was specified on any tablespace. Answer A is incorrect; permanent objects can't be created in a temporary tablespace. Answer B is incorrect; the SYSTEM tablespace will become her default tablespace, but she as yet has no quota on anything. Answer C is incorrect; although SYSTEM is her default tablespace, she has yet to be allocated a quota.

10:

User crystal has had the following ALTER USER statement run against her userid:

ALTER USER crystal
QUOTA MYDATA 0K
QUOTA MYDATA2 100M;

As soon as the command has finished, crystal attempts to add data to her address table that already existed in MYDATA and was at an extent barrier. What is the effect of the insert?

  • A. Because the table already existed, the insert was successful.

  • B. The table was automatically moved when the ALTER USER command was run, so the insert was successful.

  • C. The table still exists in the MYDATA tablespace but cannot be added to because the quota is now 0.

  • D. The table has been dropped as a side effect of the ALTER USER command, so the insert was unsuccessful.

A10:

Answer C is correct; the table exists and can be selected from, but no inserts can occur because the quota is 0. Answer A is incorrect; the quota was reduced to 0, therefore the insert failed. Answer B is incorrect; the ALTER USER statement will not move a table. Answer D is incorrect; the ALTER USER statement will not delete a table.


Chapter 16. Managing Password Security and Resources

Terms you'll need to understand:

  • FAILED_LOGIN_ATTEMPTS

  • PASSWORD_LOCK_TIME

  • PASSWORD_LIFE_TIME

  • PASSWORD_GRACE_TIME

  • EXPIRED

  • ACCOUNT LOCK

  • ACCOUNT UNLOCK

  • PASSWORD_REUSE_TIME

  • PASSWORD_REUSE_MAX

  • PASSWORD_VERIFY_FUNCTION

  • DEFAULT profile

  • RESOURCE_LIMIT

  • SESSIONS_PER_USER

  • CPU_PER_SESSION

  • CPU_PER_CALL

  • LOGICAL_READS_PER_SESSION

  • PRIVATE_SGA

  • LOGICAL_READS_PER_CALL

  • IDLE_TIME

  • CONNECT_TIME

  • COMPOSITE_LIMIT

  • ADMINISTER_RESOURCE_MANAGER

  • DBMS_RESOURCE_MANAGER

  • Pending area

  • Resource consumer groups

  • Resource plans

  • Resource directives

Concepts you'll need to master:

  • Manage passwords using profiles.

  • Administer profiles.

  • Control use of resources using profiles.

  • Obtain information about profiles, password management, and resources from the data dictionary.

Profiles are named sets of specific resource limits that can be assigned to any valid username or schema in an Oracle database. They provide a mechanism to more easily manage resource limits and password policies. This chapter provides information on using profiles to make your life as a DBA simpler.

Often it is necessary to carefully manage resource limits and user passwords. When this is the caseand let's face it, you aren't likely to be told that every user on your system should have free reign to use as much CPU and memory as she canyou can use profiles as a means to manage your resources from within the database. To use profiles, you first need to categorize related types of users in a database. Then determine how many profiles are needed at this point (you can always change it later) to be able to manage and provide equitable resources for all your different types of users. Then you must determine appropriate resource limits for each profile. Now let's get into some more detail.


Manage Passwords Using Profiles

Profiles are named sets of passwords and resource limits. They are assigned to individual users using the CREATE USER or ALTER USER command and can be enabled or disabled. Every database comes with at least one profile, the DEFAULT profile. With a profile, you can do the following:

  • Set rules for password aging and expiration.

  • Maintain password history so that you can manage reuse.

  • Set rules for password complexity and verification.

  • Set rules for account locking.

  • Set limits on CPU time and I/O operations.

  • Set limits on allowable idle time.

  • Set limits on allowable connect time.

  • Set limits on allowable concurrent sessions.

After a profile is created, the DBA assigns users to that profile. If resource limits are used, Oracle limits the database usage and resources to the defined profile.

Resource limits are assessed at the profile level, not the user level. A user who is assigned a profile inherits the resource limits of that profile.

DEFAULT Profile

When the database is created, Oracle automatically creates the DEFAULT profile. Users who have not been explicitly assigned to another profile will be assigned to DEFAULT. When DEFAULT is created, it has all its resource limits set to UNLIMITED. You, as the DBA, can change these values so that the limits in your environment reflect the default settings that you want to have applied to your average user.

Profile Usage

Profiles restrict sets of users from performing operations that require heavy use of resources. They ensure either that users log off the database when they are finished or that their session is logged off after it has been idle for a specified amount of time. You can group people and resources together based on similarities in need, a feature that is particularly useful when managing large complex databases with many different kinds of users.

Profiles have the following characteristics:

  • Assigning a profile to a user does not affect the currently logged-in session.

  • Profiles have to be assigned to users, not to roles or other profiles.

  • If you don't assign another profile to a user when that user is created, the DEFAULT profile is automatically assigned.

  • Any parameters not set within a profile will take on the values from the DEFAULT profile.

Passwords

Often, it is easier to exercise greater control over database security and password management by using profiles. You can identify similar characteristics that a given set of users has and determine password maintenance characteristics similar to those users.

Account Locking

Account locking enables the automatic locking of an account whenever a user fails to log in to the database after a specific number of attempts. Although it is true that users often forget passwords and need to be able to try a couple of alternatives before they get it right, it is also a fact that people trying to gain illicit access to a database may have a good guess at a userid but not know the password. An unlimited number of attempts may not be a wise security decision. Limiting a user to three or five invalid attempts limits your security exposure and provides users with a little guessing room for passwords they may have forgotten.

Two parameters assist the DBA with controlling account locking. FAILED_LOGIN_ATTEMPTS allows the account to be automatically locked after the value to which this parameter has been set is passed. The account is automatically locked and either can be set to automatically unlock after a specific amount of time has passed (set by the other parameter, PASSWORD_LOCK_TIME) or can be unlocked by the DBA with the ALTER USER command. If an account is locked using the ALTER USER command, it is never automatically unlocked.

Password Aging and Expiration

Password aging and expiration enable you to determine in advance a password's lifetime. After the expiration period, the password must be changed. This limits security exposure because a user who has had the same password for five years may have at some point given his password to someone else. Forcing the password to be changed limits the length of time that there is a hole in the security.

Two parameters are available to help with maintaining password aging and expiration. PASSWORD_LIFE_TIME sets the maximum lifetime after which the password must be changed (there is no minimum time that must pass before the user must change the password). You, as the DBA, can specify a grace period (specified by the PASSWORD_GRACE_TIME parameter). As soon as the PASSWORD_LIFE_TIME time has passed, at the next user login, PASSWORD_GRACE_TIME goes into effect. A warning message is generated every time the user tries to log in until the grace period has passed. The user is expected to change the password within the grace period. If the password is not changed within the grace period, the account is locked.

You can deliberately set the state of a password to "expired" by using the EXPIRED keyword in the CREATE USER or ALTER USER command. This forces the user to change his password the first time that he logs in to the system.

Password History

Password history allows you to preset an amount of time that must pass before a password can be reused. This can be set either as a specific amount of time, for example 90 days, or as a specific number of password changes, three or five or any number that you set.

Oracle provides two parameters that assist with password history maintenance. PASSWORD_REUSE_TIME specifies the given number of days that must pass before a user can reuse a previous password. PASSWORD_REUSE_MAX forces a user to arrive at a password that is not identical to earlier passwords. PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused. If you set PASSWORD_REUSE_MAX to an integer value, you have to set PASSWORD_REUSE_TIME to UNLIMITED.

If PASSWORD_REUSE_TIME is set to a value other than DEFAULT or UNLIMITED, PASSWORD_REUSE_MAX must be set to UNLIMITED.

Password Complexity Verification

Complexity verification ensures that a password fits with rules that you set up ahead of time that deal with how many characters must be in a password and the different configurations that can be used for passwords. (For example, a password must have at least one number and at least one non-number character, must not be the same or similar to your userid, must have at most one set of duplicated letters or numbers within the password, and so forth.)

When users change their passwords, before the password gets assigned, a PL/SQL function can be invoked to verify the validity of the password. Oracle provides a default verification routine, but the DBA can create an alternative PL/SQL function that is a customized way of checking the validity. The Oracle provided parameter, PASSWORD_VERIFY_FUNCTION, can be set to the custom PL/SQL function to enable the use of the custom program unit for password verification.

The Oracle provided password function takes the userid, new password, and old password as parameters and returns a Boolean value to specify its validity. The characteristics that the VERIFY_FUNCTION (the Oracle supplied SYS function for password verification) looks for follow:

  • Minimum length of password is four characters.

  • Password should not be equal to username.

  • Password should have at least one alphabetic, one numeric, and one special character.

  • Password should differ from immediately previous password by at least three letters.

To use the VERIFY_FUNCTION, you need to have run the utlpwdmg.sql script as the SYS user. This script changes the DEFAULT profile and sets the following defaults:

  • PASSWORD_LIFE_TIME = 60

  • PASSWORD_GRACE_TIME = 10

  • PASSWORD_REUSE_TIME = 1800

  • PASSWORD_REUSE_MAX = UNLIMITED

  • FAILED_LOGIN_ATTEMPTS = 3

  • PASSWORD_LOCK_TIME = 1/1440

  • PASSWORD_VERIFY_FUNCTION = verify_function

Whether or not password management is enabled in a profile, the user account can be locked or unlocked with the CREATE USER or ALTER USER command. This is the same method used to assign profiles to users, and password limits are always enforced reliably across users.


Administering Profiles

Profile administration isn't likely something that will take up a lot of your time as a DBA. After you establish a set of profiles, they are usually stable until you determine that you need to add a new one for a business purpose. This section helps with your administration tasks when you need them.

Creating Profiles

You need to create a profile if you want to centrally maintain password rules in your database.

Setting Password Limits

The following command creates a profile that sets password limits and that can later be assigned to a user group that has been determined to require this given set of limits:

CREATE PROFILE custom_grace_5 LIMIT
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_LIFE_TIME 90
PASSWORD_REUSE_TIME 360
PASSWORD_VERIFY_FUNCTION my_custom_verification
PASSWORD_GRACE_TIME 5;

The following syntax for the CREATE PROFILE command provides the basics of the creation script for password verification using the profile:

CREATE PROFILE profilename LIMIT
[FAILED_LOGIN_ATTEMPTS maximum_value]
[PASSWORD_LIFE_TIME maximum_value]
[ {PASSWORD_REUSE_TIME
|PASSWORD_REUSE_MAX} maximum_value]
[PASSWORD_LOCK_TIME maximum_value]
[PASSWORD_GRACE_TIME maximum_value]
[PASSWORD_VERIFY_FUNCTION
{custom function|NULL|DEFAULT|VERIFY_FUNCTION} ]

And the definitions of the CREATE PROFILE script follow:

  • Profile name is the name of the profile that you are creating.

  • FAILED_LOGIN_ATTEMPTS is the number of failed attempts to log in before the user account becomes locked.

  • PASSWORD_LIFE_TIME is the number of days that the user can maintain the same password. After this period, if no PASSWORD_GRACE_TIME is specified, the user account is locked.

  • PASSWORD_REUSE_TIME is the number of days that must elapse before a password can be reused. If you set this parameter to an integer, you must set PASSWORD_REUSE_MAX to UNLIMITED.

  • PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused. If you set PASSWORD_REUSE_MAX to an integer value, you have to set PASSWORD_REUSE_TIME to UNLIMITED.

  • PASSWORD_LOCK_TIME is the number of days the account will be locked after the specified number of failed login attempts locks the account. After this period, the account will automatically unlock.

  • PASSWORD_GRACE_TIME is the number of days after the grace period begins in which the user has to change the account password. If the password is not changed during this time, the password expires.

  • PASSWORD_VERIFY_FUNCTION can be set to either DEFAULT, NULL (none), the Oracle provided VERIFY_FUNCTION, or to the custom function that you create to verify passwords for the profile.

Assigning Profiles

After a profile is created, you can assign it to one or more database users. Each user can be assigned only one profile at any given time. If a user is assigned a second profile, that profile overwrites the previously assigned profile.

You can assign profiles to users with either the CREATE USER command or the ALTER USER command.

Altering Profiles

You can alter any profile that you have created with the ALTER PROFILE command. If you want to set a parameter to less than a day, you can use the following fractions or similar fractional values that will give you exactly the granularity you want (2 hours, 13 hours, 28 minutes).

  • 1 hour is 1/24.

  • 10 min is 10/1440.

  • 1 min is 1/1400.

  • 12 hours is 12/24.

Changes made to a profile take effect only on subsequent logins; currently connected sessions are not affected.

Dropping Profiles

You can drop profiles as follows when they are determined to no longer be needed:

DROP PROFILE profile_name;

or

DROP PROFILE profile_name CASCADE;

Using the CASCADE keyword revokes the profile from all the users to whom it was assigned and automatically reassigns those users to the DEFAULT profile. Use of this keyword is the only way to drop a profile that has users assigned to it. When a profile is dropped, the changes apply only to sessions that connect after the drop. Connected sessions are not affected.

You can never drop the DEFAULT profile.


Controlling Resources Using Profiles

Resource management limits can be enforced at the session level (as long as you are logged in to SQL*Plus or whatever interface you are using to interact with the database), at the individual command or query level, or both. Limits can be defined by profiles created with the CREATE PROFILE command, and resource limits are enabled with the RESOURCE_LIMIT initialization parameter or the ALTER SYSTEM command. Resource limits can be set for a profile and are enforced, but only when you enable the resource limitations for the associated database. These limitation enforcements can be enabled or disabled with either of two methods.

First, enabling limits before startup can be controlled with the RESOURCE_LIMIT initialization parameter. Valid values are TRUE or FALSE with FALSE being the default. Second, enabling limits when the database is open can be accomplished with the ALTER SYSTEM SET RESOURCE_LIMIT = TRUE|FALSE command.

When the RESOURCE_LIMIT is set to true, you can create profiles to manage resource limits.

Resource limits managed with a profile include the following:

  • SESSIONS_PER_USER is the number of concurrent sessions allowed for each username.

  • CPU_PER_SESSION is the total CPU time measured in hundredths of seconds per session.

  • CPU_PER_CALL is the total CPU time measured in hundredths of seconds per call.

  • LOGICAL_READS_PER_SESSION specifies the limitation on the number of data blocks involved in physical as well as logical reads per session. This is used to ensure that I/O intensive operations can't tie up memory and disk resources.

  • PRIVATE_SGA applies only when running in a shared server architecture and can be specified in either megabytes or kilobytes.

  • LOGICAL_READS_PER_CALL is the number of data blocks involved in logical as well as physical reads per call.

  • IDLE_TIME is the period of inactive time measured in minutes and is measured for the server process only. It does not take into account application activity; therefore, it is not affected by long-running queries.

  • CONNECT_TIME measures elapsed connected time in minutes.

  • COMPOSITE_LIMIT enables you to limit the total resource cost for a session in addition to being able to create and alter profiles as a means to set limits on specific resources. Composite limits are expressed as the weighted sum, measured in service units, of a set of resources. Accurate composite limits depend on the total amount of a resource used by an average profile user. Historical information should be gathered as a means of determining the normal range for the composite usage for a typical user. CPU_PER_SESSION, LOGICAL_READS_PER_SESSION, CONNECT_TIME, and PRIVATE_SGA are all weight-able resources, and if you don't assign a value to a given resource, that resource assumes a weight of 0 and does not contribute to the composite.

Call level limits are enforced for each call made while executing a SQL statement. Whenever a call level limit is exceeded, the processing of the statement is halted, the statement is rolled back, all previous statements remain intact, and the user's session remains connected.

To create a profile that limits resources, you can issue a command similar to the following:

CREATE PROFILE my_resource_profile LIMIT
SESSIONS_PER_USER 5
CPU_PER_SESSION 1000
IDLE_TIME = 120
CONNECT_TIME = 360;

After you set the RESOURCE COST, as in the following example, and determined the COMPOSITE_LIMIT for a profile, Oracle calculates the total resource cost by multiplying the amount of each resource used by the session by the resource's weight and sums all the products for all resources.

The following example shows how you would alter a profile's settings:

ALTER RESOURCE COST
CPU_PER_SESSION 10
LOGICAL_READS_PER_SESSION 100
CONNECT_TIME = 2;

The weighted cost formula, then, for a given session would be

COST = (10 * CPU_PER_SESSION) + (100 * LOGICAL_READS_PER_SESSION) + (2 * CONNECT_TIME)

Be careful when determining composite limits and carefully consider the math. If the COMPOSITE_LIMIT is not assigned a high enough value, users with the given profile could be unable to connect because the COMPOSITE_LIMIT is lower than the COST of connecting.

The values multiplied by the weights are gleaned from the profile to which the user is assigned.

By default, the DEFAULT profile has all parameters set to UNLIMITED.

We will now look at using the Database Resource Manager to create and control resource plans and consumer groups.


Managing Resource Plans and Consumer Groups

The primary goal of the Database Resource Manager is to give the Oracle Server more control over resource management decisions. In this way, Oracle can circumvent any problems that may otherwise arise from inefficient operating system management.

Your database may encounter many problems when the database resource allocation decisions are allowed to be managed only at the operating system level as follows:

  • Excessive overhead can result from operating systems that constantly switch between Oracle processes, particularly when the number of server processes is high.

  • Inefficient scheduling can occur when the operating system unschedules services when it is inefficient to the database to do so.

  • Inefficient resource allocation can occur when the operating system strives to distribute resources equally among all active processes and is therefore unable to intelligently prioritize between different tasks.

  • Database-specific resources are often beyond the capability of the operating system to manage. This is particularly true for parallel execution servers and active sessions.

To the rescue, Oracle Database Resource Manager.

Oracle Database Resource Manager

The Oracle Database Resource Manager helps overcome the inefficiencies of the operating system to deal with Oracle-specific issues pertaining to resource allocation. The Database Resource Manager allows the database to maintain more control over the way in which the machine resources are allocated.

Through the Database Resource Manager you can guarantee that a minimum amount of processing resources is available to the database regardless of the load on the system or the number of concurrent users. Resource Manager can allow for the distribution of available processing resources by allocating a percentage of CPU time to different sets of users and applications and limit the degree of parallelism of any given operation performed by a group of users. Through this mechanism, you can create an active session pool that consists of a specific number of user session connections, and sessions beyond that maximum number get queued.

The Database Resource Manager has several components created through the use of the DBMS_RESOURCE_MANAGER package. Use of the DBMS_RESOURCE_MANAGER requires both ADMINISTER_RESOURCE_MANAGER privileges and the following of the next several sections. These sections provide details about these components and explain how they can be used.

Pending Area

Before you can modify an old resource plan or create a new plan, you have to first activate, or create, a pending area using the Database Resource Manager package. All the resource plans that you create will be stored in the data dictionary. The pending area that you create with the following command allows you to work with the resource plans in a staging area before they are implemented. The following command creates the pending area:

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA;

This command clears the pending area:

EXECUTE DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA;

In this preproduction pending area, you can validate changes before their implementation.

Resource Consumer Groups

After you create the pending area, you are ready to create consumer groups to which you will allocate your users. Users can be created in one group and later changed to another group as the need arises.

Resource consumer groups are user sessions grouped together based on resource and processing requirements. A resource plan can have many consumer groups associated with it.

When you create the consumer group, you can specify the following parameters:

  • CONSUMER_GROUP or the name of the group that you are creating.

  • COMMENTS include any comments that you want to include concerning your new group.

  • CPU_MTH is the CPU allocation method to be used for the consumer group. The default (and only available as yet) method for resource allocation is ROUND-ROBIN.

There are two Oracle provided consumer groups. These two groups cannot be changed or deleted. The groups are as follows:

  • DEFAULT_CONSUMER_GROUP is the default initial group for users and sessions that have not been assigned to any other initial group.

  • OTHER_GROUPS isn't really a complete group because you can't assign users to it. Whenever a resource plan is active, the OTHER_GROUPS group is the catchall term for all sessions that don't belong to the active resource plans. You must assign a resource directive for this group in any active resource plan.

A group can be created with the following command:

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP;;

Resource Plans

Now you need to create a resource plan. Resource plans are associated with a resource plan directive, each of which specifies which resources are allocated to a consumer group.

Resource plans contain directives that specify how resources are allocated to a resource consumer group. These plans specify the resource consumer groups that belong to the plan and contain directives for how resources can be allocated among the groups.

Figure 16.1 shows a simple single level resource allocation plan that might be set up for use by the Accounting Department's members. Notice the distribution of CPU allocation.

Figure 16.1. Example of a simple resource plan.

You can specify parameters for the resource plan just as you can for the resource group. These parameters are as follows:

  • PLAN is the plan name.

  • COMMENT is any descriptive comments relevant to the plan.

  • ACTIVE_SESS_POOL_MTH is the method used for managing the resources for the active session pool. The maximum number of active sessions allowed within a consumer group designates the active session pool. When a session cannot be initiated because the pool is full, the session is placed into a queue. When an active session completes, the first session in the queue is scheduled for execution.

  • CPU_MTH is the method for allocating the CPU among the groups (again, this as yet can take on only the value of ROUND_ROBIN).

  • PARALLEL_DEGREE_LIMIT_MTH specifies the resource allocation method to be used that will effect a specified degree of parallelism in operations within the given resource group.

  • QUEUEING_MTH specifies the queuing resource allocation method.

Now that we have discussed many of the procedures that can be called through the DBMS_RESOURCE_MANAGER let's look at creating a plan. The following code can be used to create a resource plan:

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN (plan_name);

Automatic Consumer Group Switching

Automatic consumer group switching allows you to control resources by specifying criteria, and if the criteria isn't met this causes the automatic switching of sessions to another consumer group. The criteria used to determine switching include the use of the following parameters:

  • SWITCH GROUP is the group to be switched to.

  • SWITCH TIME is the switch time in seconds.

  • SWITCH ESTIMATE is the estimate of how long the operation will take to complete. This is used to decide whether to switch an operation even before it starts.

Resource Allocation Methods

Resource allocation methods are the methods and policies used by the Database Resource Manager when allocating a particular resource. These methods are used by resource consumer groups and resource plans.

Resource Plan Directives

Resource plan directives are used by administrators to associate resource consumer groups with resource plans and to allocate resources among the resource consumer groups.

[View full width]

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( PLAN=> 'myplan', GROUP_OR_SUBPLAN =>
   'mygroup'

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'myplan', GROUP_OR_SUBPLAN =>
   'mygroup2', CPU_P1 = 50);

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN (=> 'myplan', GROUP_OR_SUBPLAN =>
   'OTHER_GROUPS', CPU_P1 = 100);

The set of directives created in the preceding code assigns 50% of the available CPU to the myplan plan and its group mygroup and 50% to mygroup2.

Make sure that you include a resource directive for the OTHER GROUPS group. If OTHER_GROUPS is not defined, Oracle won't let you use your plan for any groups.

Assigning Users to Consumer Groups

You can now assign users to the consumer groups. You will normally have several users in each group.

Before you can assign users to their groups, you need to grant the users privileges to set initial groups and switch groups among other things. This can be accomplished quickly and elegantly by granting the privileges to PUBLIC.

You need to execute the following package procedures to be able to assign and reassign users to different consumer groups:

  • DBMS_RESOURCE_MANAGER.GRANT_SWITCH_CONSUMER_GROUP

  • DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP

  • DBMS_RESOURCE_MANAGER.GRANT_SWITCH_CONSUMER_GROUPS

Enabling Database Resource Manager

Just because you have created all the plans, plan directives, and groups doesn't mean that you can automatically use them. For Oracle to be able to enforce the resource plans, you need to explicitly activate the Resource Manager, either by specifying the initialization parameter RESOURCE_MANAGER_PLAN in the initialization parameter file or by using the ALTER SYSTEM command as follows:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=myplan;

Deactivating the plan can be done as follows:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=myotherplan;


Data Dictionary Information About Profiles, Password Management, and Resources

Table 16.1 provides a list of all the views that can be used to get information on users, their passwords, profiles, and resources.

Table 16.1. Data Dictionary Views for Profiles

View

Description

DBA_USERS

The DBA view describes all the users of the database.

ALL_USERS USER_USERS

The ALL view lists all the users of the database, but does not describe those users. The USER view describes only the currently connected user.

DBA_TS_QUOTAS USER_TS_QUOTAS

Describes tablespace quotas for users: DBA for all users, and USERS for just the connected user.

USER_PASSWORD_LIMITS

Describes the password profile parameters that have been assigned to the connected user.

USER_RESOURCE_LIMITS

Displays the resource limits assigned for the current user.

DBA_PROFILES

Displays all profiles in the database and all their limits.

RESOURCE_COST

Lists the costs that have been assigned for each resource.


Exam Prep Questions

1:

What is the name of the staging area in which you build the resource plan?

  • A. Staging area

  • B. Temporary area

  • C. Pending area

  • D. Building area

A1:

Answer C is the correct answer; you create resource plans in the pending area. Answer A is incorrect; although it can be considered to be a staging area, it is called a pending area. Answers B and D are not areas in the database.

2:

The SWITCH_GROUP parameter specifies which of the following:

  • A. The consumer group that is a switchable consumer group

  • B. The group that can have its status toggled between on and off

  • C. The group to which a session will be switched when the session meets preestablished criteria

  • D. The group from which the session will be switched when the session meets preestablished criteria

A2:

Answer C is correct; SWITCH_GROUP is the group to which a session will switch when it meets preexisting criteria. Answer A is incorrect; all consumer groups are switchable under defined circumstances. Answer B is incorrect; you cannot toggle groups off and on. Answer D is incorrect; it is the group to which the session will switch, not from which it will switch.

3:

From which data dictionary view can you determine what profile has been assigned to a given user?

  • A. DBA_USERS

  • B. DBA_PROFILES

  • C. DBA_RESOURCE_LIMITS_SET

  • D. V$USER

A3:

Answer A is correct; you can determine the profile assigned to any given user. Answer B is incorrect; DBA_PROFILES tells you the profiles in the database and their limits, but not to whom they have been assigned. Answers C and D are incorrect because they are not valid data dictionary views.

4:

You have created the following profiles in your database: DEVELOPERS for programmers, MANAGERS for managers, ACCOUNTING for people in the accounting department, CLIENTS for external users of the database, and OUSERS for everyone else. You have just been notified that you need to create a userid for a new regular user employee (Frieda), and you run the following command:

CREATE USER Frieda IDENTIFIED BY peanut PASSWORD EXPIRE ACCOUNT UNLOCK;

To which of the following profiles has Frieda been assigned?

  • A. OUSER

  • B. DEVELOPER

  • C. ACCOUNTING

  • D. DEFAULT

A4:

Answer D is correct; because you have not deliberately assigned Frieda to any profile, she will default to the DEFAULT profile. Answer A is incorrect; you may have meant for her to be assigned to the OUSER profile, but it needs to be assigned deliberately. Answers B and C are also incorrect because Frieda was not assigned to any profile and so has by default been assigned to DEFAULT.

5:

You have decided that you need to do some serious reorganization of your profiles in your database and move to a standard naming convention for the profiles in the database. In the process, you decide that you have to drop the dev01 profile and reassign its users to the DEVELOPER profile. How can you drop the dev01 profile and still allow your users to access the database while you are building the new profile?

  • A. DROP PROFILE dev01;

  • B. DROP PROFILE dev01 CASCADE DELETE;

  • C. DROP PROFILE dev01 CASCADE;

  • D. You have to wait till the DEVELOPER profile is ready to use to switch them to the new one, or they won't be able to connect.

A5:

Answer C is correct; you need to issue the DROP PROFILE command with the CASCADE keyword to drop the profile and have it automatically unassigned to all the users. Answer A is incorrect; it will drop the profile but will not unassign the profile from the users and would therefore error if any users were assigned. Answer B is incorrect; you don't CASCADE DELETE. The DELETE keyword would cause the command to fail. Answer D is incorrect; when you drop the profile, the users will be reassigned to the DEFAULT profile and will be able to continue to connect successfully.

6:

Your company has decided to implement a password expiration plan. What parameter do you need to set to cause all passwords to expire every 60 days?

  • A. PASSWORD_LIFE_TIME

  • B. PASSWORD_EXPIRATION_DAYS

  • C. PASSWORD_REUSE_TIME

  • D. PASSWORD_GRACE_TIME

A6:

Answer A is correct; PASSWORD_LIFE_TIME allows you to set the maximum number of days that can pass before the password is expired. Answer B is incorrect; it is not a valid parameter for password maintenance. Answer C is incorrect; PASSWORD_REUSE_TIME sets the amount of days that must pass before a password can be reused again. Answer D is incorrect; PASSWORD_GRACE_TIME is the period in which you have to change your password after it has expired.

7:

You have created the following profile in your development database:

CREATE PROFILE limit_programmers LIMIT
SESSIONS_PER_USER 2
CPU_PER_CALL 100
CONNECT_TIME 480
IDLE_TIME 45;

How will Oracle determine the value of CPU_PER_SESSION?

  • A. It will get the value from the DEFAULT profile and use that value.

  • B. It will multiply CPU_PER_CALL by the average number of calls that the user can make in a given CONNECT_TIME session to determine what CPU_PER_SESSION should be.

  • C. It will use the CPU_PER_CALL and sets CPU_PER_SESSION to that value as well.

  • D. It will not set the value of CPU_PER_SESSION for this profile.

A7:

Answer A is correct; it will take the value from the DEFAULT profile whether or not you have changed its values and set the CPU_PER_SESSION to whatever the current value of that parameter is in the DEFAULT profile. Answer B is incorrect; Oracle won't do math to infer a value for a parameter. Answer C is incorrect; Oracle won't set the parameter based on another parameter name. Answer D is incorrect; the parameter will be set with an inferred value from DEFAULT.

8:

You want to use composite resource limits in your new Oracle database. Which of the following commands must be issued first so that your profiles' composite resources will be assigned a value for your composite limits?

  • A. ALTER PROFILE

  • B. ALTER SYSTEM

  • C. ALTER RESOURCE COST

  • D. ALTER USER

A8:

Answer C is correct; you need to issue the ALTER RESOURCE COST command to set the weighted values for the resources in your system. Answer A is incorrect; you can't alter the profile to set the resource weights. Answer B is incorrect; composite limits are connected to resources and profiles, not directly to the system. Answer D is incorrect; you do not have to alter individual users to make use of the changes to the profiles or to the resource weights.

9:

What initialization parameter must be set for Oracle to enforce the resource limits according to your profile settings?

  • A. RESOURCE_LIMITS

  • B. PROFILE_LIMITS

  • C. ALLOW_PROFILES

  • D. PROFILE_OPTION_VALUES

A9:

Answer A is correct; you set RESOURCE_LIMITS to trUE to be able to enforce resource limits in your database. Answers B, C, and D are incorrect; they are not valid parameters for the initialization file.

10:

What Oracle-supplied package do you use to maintain your Resource Manager components?

  • A. DBMS_RES_MAN

  • B. DMBS_RESOURCE_MANAGER

  • C. DBMS_MANAGE_RESOURCES

  • D. RMAN

A10:

Answer B is correct; DMBS_RESOURCE_MANAGER is the package that you use to help with resource manager management. Answers A and C are not part of the database. Answer D is incorrect; RMAN is a recovery manager and is used for backup and recovery, not resource management.


Chapter 17. Managing Privileges

Terms you'll need to understand:

  • DBA_SYS_PRIVS>

  • SESSION PRIVS

  • DBA_TAB_PRIVS>

  • DBA_COL_PRIVS>

  • ALL_DEV_AUDIT_OPTS

  • DBA_STMT_AUDIT_OPTS>

  • DBA_PRIV_AUDIT_OPTS>

  • DBA_OBJ_AUDIT_OPTS>

  • DBA_AUDIT_TRAIL>

  • DBA_AUDIT_EXISTS>

  • DBA_AUDIT_OBJECT>

  • DBA_AUDIT_SESSION>

  • DBA_AUDIT_STATEMENT>

  • Grant

  • Revoke

  • System privileges

  • Object privileges

Concepts you'll need to master:

  • Identify system privileges.

  • Identify object privileges.

  • Grant and revoke privileges.

  • Identify auditing capabilities.

Users can do very little, nothing in fact, until they have been granted certain privileges. Everything in Oracle is controlled either directly through granting privileges or indirectly through groups of privileges called roles, covered in Chapter 18, "Managing Roles." This chapter deals with the building blocks called privileges.

A privilege is a deliberately granted or an inferred right to access and execute a given program or to view or alter data.

Oracle has two different types of privileges: system privileges> and object privileges>. The following section covers system privileges.


System Privileges

System privileges allow users to perform particular database operations or groups of database operations.

Oracle provides more than 100 separate and distinct system privileges. Many have different variations based on exactly what the user needs to be able to do.

The privileges have three basic types of classifications: systemwide operations, object management operations in a user's own schema, and object management operations in any user's schema.

Systemwide operations include the capability to create a session (CREATE SESSION privilege) or to create tablespaces (CREATE TABLESPACE privilege). Only a database administrator or someone who has that role can grant systemwide operation privileges.

Schema object management operations include things such as CREATE TABLE.

Object management operations on schemas other than the user's own schema are accomplished through the use of the ANY keyword, such as CREATE ANY TABLE.

Granting and revoking privileges is accomplished through the use of the DDL commands GRANT and REVOKE.

Table 17.1 provides an overview of the most commonly used system privileges.

Table 17.1. System Privileges

Category

Examples

Explanation

INDEX

CREATE ANY INDEX

Allows you to create any index on any user's table.

ALTER ANY INDEX

Allows you to alter any index in any user's schema.

DROP ANY INDEX

Allows you to drop any index on any table in any user's schema.

TABLE

CREATE TABLE

Allows a user to create a table in his own schema. CREATE TABLE infers also ALTER TABLE, DROP TABLE, UPDATE TABLE, DELETE TABLE, TRUNCATE TABLE, and SELECT TABLE.

CREATE ANY TABLE

Allows a user to create a table in any schema. This privilege implies both CREATE INDEX and INSERT TABLE.

ALTER ANY TABLE

Allows a user to alter any table in any schema.

DROP ANY TABLE

Allows a user to drop any table in any schema in the database. Oddly, this is also the privilege that allows a user to truncate a table that does not belong to his or her schema.

SELECT ANY TABLE

Allows a user to select any information from any table from any schema in the database.

UPDATE ANY TABLE

Allows a user to update or insert information into any table in any schema in the database.

DELETE ANY TABLE

Allows a user to delete any data out of any table in any schema in the database.

INSERT ANY TABLE

Allows a user to insert data into any table in any schema in the database.

ACCESS

CREATE SESSION

Allows a user to create a session. This is the first and most important privilege that a user can be granted. Without the ability to create a session, all other privileges are irrelevant.

ALTER SESSION

Allows a user to change settings associated with his session with the ALTER SESSION command.

RESTRICTED SESSION

Use this with great care. Allows users to access the database when it is started in restricted mode; this is typically done when the DBAs are doing maintenance.

TABLESPACE

CREATE TABLESPACE

Allows a user to create any tablespace in the database.

ALTER TABLESPACE

Allows a user to alter any tablespace in the database.

DROP TABLESPACE

Allows a user to drop any tablespace in the database.

UNLIMITED TABLESPACE

Allows a user to use as much space in the database as they want to or can. Again, use with caution. Can only be granted to a user, never to a role. This is implicitly granted with the RESOURCE role (see Chapter 18).

Administration Functions

ALTER SYSTEM

Allows a user to alter the system state.

AUDIT SYSTEM and AUDIT ANY

Allows a user to audit the system state (AUDIT SYSTEM) or to audit anything in the database (AUDIT ANY).

ANALYZE ANY

Allows a user to analyze any table, schema, or index in the database.

ALTER DATABASE

Allows a user to alter the state of the database.

GRANT ANY PRIVILEGE

Allows a user to grant any privilege to any user.

Users

CREATE USER

Allows a user to create other users.

BECOME USER

Allows a user to become other users.

ALTER USER

Allows a user to alter other users.

DROP USER

Allows a user to drop other users.

You will notice that there is no corresponding CREATE INDEX privilege to go along with the CREATE TABLE privilege like there is for the CREATE ANY INDEX for the CREATE ANY TABLE privilege. This is because the CREATE TABLE privilege infers both CREATE INDEX and ANALYZE privileges. However, what is not inferred is the user's space allocation for the tablespace in which the table is being built. It is necessary to grant everyone who will be creating tables enough space in the tablespace that you want the tables to be built in to facilitate the table building.

CREATE TABLE, CREATE PROCEDURE, and CREATE CLUSTER infer the privilege of dropping these objects as well.

To grant system-level privileges, you have to be logged in to the database as a user with DBA privileges, and they are granted with the following SQL statements:

GRANT CREATE SESSION TO amandya;

or

GRANT CREATE SESSION TO adam WITH ADMIN OPTION;

The WITH ADMIN OPTION keywords signify that the user to whom these privileges have been granted has the ability to further grant the same privileges to other users.

Be judicious with your use of the WITH ADMIN OPTION. The ability to pass on privileges in this manner is usually reserved for someone with security administration status in the organization.

Granting a privilege to PUBLIC has the effect of granting that privilege to all users of the database regardless of other privileges that have been granted.

What can be granted can also be revoked. The following command revokes the CREATE ANY TABLE privilege from the user larry:

REVOKE CREATE ANY TABLE FROM larry;

One reason that it is important to carefully consider to whom you grant privileges WITH ADMIN OPTION is connected to the revoking of privileges.

When you grant system privileges and then decide to revoke those privileges, there is no cascading effect of revoking. This may be what you need to have happen, as in the case of a security administrator granting privileges and then moving on to a new position. In this case, you would probably want everyone to whom that user granted SELECT ANY TABLE to be able to use that privilege even though you have revoked the administrator's privileges. But consider the following example.

As a DBA, you grant the CREATE TABLE system privilege to Larry WITH ADMIN OPTION, and Larry creates a few tables. Later, Larry grants the CREATE TABLE privilege to Crystal, and she creates several tables. Larry moves into management and therefore no longer needs to be able to create tables. You revoke the CREATE TABLE privilege from him, but you don't know about Crystal having the same privilege. Now, Larry's tables still exist, but he can't create any more tables. Crystal's tables still exist, and she can continue to create tables because she retains the CREATE TABLE privilege.

Special System Roles

Although Chapter 18 covers roles, two notable roles should be discussed at this point: SYSOPER and SYSDBA.

SYSOPER

SYSOPER has the privileges of STARTUP, SHUTDOWN, ALTER DATABASE OPEN, ALTER DATABASE MOUNT, ALTER DATABASE BACKUP CONTROLFILE, RECOVER DATABASE, and ALTER DATABASE ARCHIVELOG. SYSOPER is often used when an organization needs to provide certain people with limited authority. Often this is done so that computer operations personnel can shut down the database to take a cold backup and then bring the database back up.

SYSDBA

SYSDBA has all the privileges that SYSOPER has all WITH ADMIN OPTION, plus CREATE DATABASE, ALTER DATABASE BEGIN BACKUP, ALTER DATABASE END BACKUP, RESTRICTED SESSION, and RECOVER DATABASE UNTIL.

There exists in Oracle 9i a dictionary protection mechanism created to prevent unauthorized users from accessing data dictionary objects. Ordinarily in 9i, access to the data dictionary objects requires the use of the two restricted roles of SYSDBA and SYSOPER, and even the granting of the SELECT ANY TABLE privilege wouldn't provide access to these views, their base tables, or synonyms.

The O7_DICTIONARY_ACCESSIBILITY initialization parameter controls access to the objects in the SYS schema (the objects in the data dictionary) to only SYSDBA and SYSOPER. If set to FALSE, the default, it ensures that the system privileges that allow you to access any schema don't allow you to access the SYS schema. Conversely, if set to TRUE, access to objects in SYS are allowed with the granting of the ANY privileges (SELECT ANY TABLE or EXECUTE ANY PROCEDURE). The parameter's name means that Oracle is allowing you the access that was available in Oracle 7 (hence, the O7) as far as data dictionary accessibility. Consider carefully your use of the parameter. There are alternatives that would be less dangerous. Granting the SELECT ANY DICTIONARY privilege allows select privileges on all the data dictionary views without having to grant the users SELECT ANY TABLE privileges and limiting the damage that could be done with a userid that has DELETE ANY TABLE.

The second type of privilege in the database is object privileges. These are covered in the following section.


Object Privileges

Object privileges allow users to perform particular and controlled actions on specific objects. They allow for a finer grain of control with respect to the objects that can be accessed and the functions that can be performed with those objects. You can allow a user to SELECT, INSERT, UPDATE, and DELETE from just a single table.

The only two privileges that you can grant concerning the manipulation of an existing sequence are SELECT and ALTER.

Table 17.2 shows all the object privileges that you should know for the exam.

Table 17.2. Oracle 9i Object Privileges

Privilege

Description

SELECT

Permits grantee user to select data from granter's table

INSERT

Permits grantee user to insert data into granter's table

UPDATE

Permits grantee user to update rows in granter's table

DELETE

Permits grantee user to delete data from granter's table

ALTER

Permits grantee user to alter the definition of a table or sequence

INDEX

Permits grantee user to create an index on granter's table

REFERENCES

Permits grantee user to create or alter a table to create a foreign key constraint against the data in the referenced table

EXECUTE

Permits grantee user to run a stored procedure or function in the granter's schema

Further granularity of control over REFERENCES (creating foreign key constraints on a table outside a user's own schema) and INSERT can be restricted to specifying a certain subset of updatable columns. SELECT can be restricted further by the creation of a view on the allowable columns and granting SELECT on the view rather than on the table underlying the view.

A grant to any synonym is automatically converted to a grant on the table underlying that synonym. A grant on a view relates only to that view.

The GRANT statement is a little different for object privileges than it is for system privileges because you have to include the objects on which you are granting the privileges:

GRANT UPDATE ON mydata TO amandya;
GRANT SELECT ON addresses TO amandya WITH GRANT OPTION;

As you can see, object privileges can also be granted WITH GRANT OPTION so that the user to whom they have been granted can further grant those same privileges to someone else.

Revoking privileges likewise requires the object on which the privilege was granted to be included in the revocation statement:

REVOKE SELECT ON addresses FROM lonny;

You can revoke privileges only from those users to whom you have granted privileges.

Unlike the WITH ADMIN option on system privileges, with object privileges, cascading effects can be observed when using the WITH GRANT OPTION.

For example, Lynn is granted UPDATE privileges on Lonny's address table WITH GRANT OPTION. She grants UPDATE privileges to Freeman. Later, the UPDATE privileges granted to Lynn are revoked, and that revoke is cascaded to Freeman as well.

Now that you know how to grant and revoke privileges on different levels to users in the database, you might find that you need to monitor the user actions in the database. The following section provides information on auditing.

Make sure that you can distinguish between object privileges and system privileges in Oracle. The easiest way to do this is to memorize what the object privileges are and to assume that everything else is a system privilege.


Auditing Capabilities

Auditing, in Oracle, is used to assist the DBA with investigating suspicious database activity or to gather information about certain specific database activities.

You may determine that an unauthorized user is deleting data. In that case, the DBA, or a security administrator, might decide that she needs to audit all the connections to the database and all the successful or unsuccessful deletions of data from all the tables in the database for a given period of time. Oracle provides facilities to enable the DBA to gather statistics not only on who has been connecting to the database to learn about the unauthorized deletions but also to gather information on how many logical I/O operations have been performed at peak times or how many concurrent users have been connected during that peak time.

First, you need to determine exactly what you want to monitor. Auditing information can become voluminous, so you want to turn on auditing judiciously. Do you want to audit users, statements, or objects? Do you want information on all statement executions or just successful statement executions or just unsuccessful statement executions?

After you have an idea of what you want to audit, you need to consider how you are going to monitor and manage the growth of the audit trail and also how you are going to protect that audit trail from unauthorized access.

You want to first identify the requirements and then set the minimal auditing options that will meet your predetermined requirements. Specific object auditing should be used when possible to reduce the volume of data generated. If you determine that you really do need statement or broader yet privilege auditing, you can minimize the impact of this auditing by following these guidelines:

  • Limit the users you are auditing.

  • Audit by session not by access.

  • Audit by success or by failure but not both success and failure.

  • Audit only when absolutely necessary.

  • Be highly selective of the audit options.

  • Be aware that users can turn on auditing for objects that they own.

  • Use the AUDIT ANY privilege judiciously because it enables the user to turn on auditing at any level.

  • Periodically purge audit records from the audit trail. This can be done either with DELETE or trUNCATE (if you want to maintain a backup, insert the records into a backup table first). The audit files are located in the %ORALE_HOME%\rdbms\audit directory.

  • Protect the audit trail from manipulation by either auditing the deletions on SYS.AUD$ by access (AUDIT DELETE ON SYS.AUD$ BY ACCESS) or by only allowing the DBA to have the DELETE_CATALOG_ROLE.

You can specify that records be written to SYS.AUD$, or to the operating system's audit trail, depending on the operating system that you are on.

If the audit trail becomes too full, no more records can be inserted, and all future audited statements will no longer perform successfully. Errors will be returned to all users that the audited statement has failed (making the auditing less effective), and you will need to free space in the audit trail for the statements to execute.

It is important to remember that you should always temper the need to audit and track who's doing what in your database with the knowledge that turning on auditing at any level adds overhead to the database and will have some impact on performance. Understanding exactly what you are trying to accomplish with the auditing is critical.

Do you really care who queries all the tables in the database and what queries they are running? Or do you only care who is querying the salary table? Better yet, don't you want to know mostly when a row is inserted or updated?

Balancing the necessary overhead with the added security is a job almost in itself.

Moving the Audit Trail Out of the SYSTEM Tablespace

As a general rule, you shouldn't move around the objects in the SYSTEM tablespace. However, as records begin to be inserted in the audit trail, the AUD$ table can begin to grow considerably. Although you should also not drop the AUD$ table, you can delete from it or truncate it to limit its growth. Because this table can grow and shrink, it should be placed outside the SYSTEM tablespace. To move the table, take the following steps:

The step should be run either as the system user, the SYS user, or the user who is the owner of the tables depending on what level of auditing you want to enable.

1.
Make sure that auditing is turned off.

2.
Issue the following command:

ALTER TABLE aud$ MOVE TABLESPACE audit_data;

3.
Create an index on the table with the command

CREATE INDEX i_aud1 ON aud$(sessionid, ses$tid) TABLESPACE audit_indexes;

4.
Reenable auditing.

Auditing Categories

By default, instance startup and shutdown and all administrator privileges are all audited. During startup, the user terminal used to start the database is recorded, the date and time stamp of the operation are recorded, and database auditing is enabled or disabled. At shutdown, the terminal and the date and time stamp of the operation are recorded. Administrator privileges record the operating user connecting to Oracle with administrator's privileges (SYSDBA, SYSOPER).

Database level auditing is enabled by the DBA and can record information about events against the database. The audit trail at this level can be used to investigate unauthorized deletion of data, or unauthorized manipulation of other structures. Another use of this level of auditing can be to determine growth of operations on the database. The DBA might gather statistics about which tables are being updated, how many logical I/O operations are being performed, and how many concurrent users are connected at highly active times. This level of auditing cannot record column values.

Value-based or application-level auditing can be implemented through custom code, can record column values, and can be used to track changes to tables. This level of auditing can be implemented often through the use of triggersfor example, before update triggers or through stored procedures.

Enabling and Disabling Auditing

To enable auditing for a given instance, you need to set the AUDIT_TRAIL initialization parameter. This parameter's purpose is to indicate whether the audit trail is written to the database table, to the operating system's audit trail, or whether auditing is turned off.

The following is a list of locations where the audit trail will be stored:

  • AUDIT_TRAIL = DB enables auditing and causes all audit records to be sent to the database audit trail in the SYS.AUD$ table.

  • AUDIT_TRAIL = OS enables auditing and sends all audit records to the operating system's audit trail if the operation is permitted by the operating system. These logs go to the $ORACLE_HOME/rdbms/audit or the %ORACLE_HOME%\rdbms\audit directory.

  • AUDIT_TRAIL = NONE (the default) causes auditing to be disabled.

Although the statements AUDIT or NOAUDIT can be used at any time, the audit records will not actually be retained unless the DBA has set the AUDIT_TRAIL parameter to either OS or DB.

You use the NOAUDIT command to stop auditing the chosen AUDIT option.

You must use exactly the same syntax in the NOAUDIT command that you used in the AUDIT command for which it is intended to reverse. Further, it will only undo the specific auditing of the exact AUDIT command that it sets the NOAUDIT for.

Audit Options

After you have enabled the retention of audit records, you can set the specific auditing options using the AUDIT command. With this command, you indicate which commands, which users, which objects, or which privileges you want to audit. You can assign the generation time of audit records at the same time. You can either have records generated at each occurrence or have them generated only once per session, and you can turn off auditing on the object that you have been auditing with the NOAUDIT command.

You can selectively audit statements but not the underlying specific schema objects on which the statement operates. AUDIT TABLE tracks the DDL statements in the database regardless of the table on which those statements are issued.

You can audit privileges that correspond to selective system privileges such as auditing the creation of triggers in the database:

AUDIT CREATE ANY TRIGGER;

You can audit schema objects. This is the most narrow and selective of auditing options. With this, you can turn on auditing for specific statements on particular objects, as in the following command:

AUDIT SELECT ON payroll;

Schema object auditing applies to all users of the database performing the given action on the given object.

You can further narrow the criteria by adding the following conditions to any given AUDIT statement:

  • WHENEVER SUCCESSFUL

  • WHENEVER NOT SUCCESSFUL

  • BY SESSION

  • BY ACCESS

Statement Execution

Every time users execute a PL/SQL statement or a SQL statement, Oracle examines the auditing options and determines whether the statement should generate an audit record. SQL statements located inside PL/SQL programs are all examined individually and are individually audited if necessary. Because views, packages, and procedures may refer to other database objects, several audit records may be generated as a result of executing a single statement.

Audit Data Generation

The generation of an audit record is independent of a user's transaction. This means that if a user's transaction is rolled back, the audit trail of that transaction remains intact. In this way, you are alerted to the attempt at the statement. However, because the audit record is generated while running the execute phase, a syntax error that occurs during the parse phase will not cause a record to be generated.

Reviewing Audit Information

You can examine the information generated during auditing by selecting directly from the audit trail data dictionary views, or you can use the operating system's utilities to view the operating system's audit trail. Because this is an ordinary flat file, you can at least look at the file's contents with any flat file text editor.

Use the information that you have gathered to investigate database activity either for suspicious activity or for planning information for future growth.

Fine-Grained Auditing

Fine-grained auditing provides for the monitoring of data access based on content and is implemented through the use of the DBMS_FGA package. When the DBA uses the DBMS_FGA package, she can create an audit policy on the target table, and, if any rows returned form a query block match the audit condition, an audit event entry (complete with username, SQL text, bind variables, policy name, session ID, date, and time stamp) and other attributes of the event are inserted into the audit trail. This can be used to alert someone of unauthorized access of salary information or unauthorized access of sensitive medical history data.


Data Dictionary Information

You can, again, find information concerning both auditing and privileges in the data dictionary, but only if you have SYSOPER, SYSDBA, or privileges to view the views.

The following list of data dictionary views provides information on auditing:

  • DBA_SYS_PRIVS contains a list of all the system privileges granted to users or to roles.

  • SESSION PRIVS contains a list of all the system-level privileges currently available to the given user.

  • DBA_TAB_PRIVS contains a list of all the grants on any objects in the database (the TAB in the name is misleading in this case; it is not just on tables).

  • DBA_COL_PRIVS lists all the object column grants in the database.

  • ALL_DEF_AUDIT_OPTS lists all the default audit options.

  • DBA_STMT_AUDIT_OPTS lists all statement auditing options.

  • DBA_PRIV_AUDIT_OPTS lists all privileges auditing options.

  • DBA_OBJ_AUDIT_OPTS lists all schema object auditing options.

  • DBA_AUDIT_TRAIL provides access to all audit trail entries.

  • DBA_AUDIT_EXISTS provides access for all audited EXISTS/NOT EXISTS statements.

  • DBA_AUDIT_OBJECT contains records concerning schema objects.

  • DBA_AUDIT_SESSION contains records concerning all connect and disconnect entries.

  • DBA_AUDIT_STATEMENT contains statement auditing records.


Exam Prep Questions

1:

You have granted user Haylee the SELECT ANY TABLE privilege WITH ADMIN OPTION. Haylee has granted SELECT ANY TABLE to Blaine and Garrison. After you realize that you granted Haylee the wrong privileges, you revoke her SELECT ANY TABLE privilege. What is the status of Blaine and Garrison?

  • A. Blaine can select from any table, but Garrison cannot.

  • B. Garrison can select from any table, but Blaine cannot.

  • C. Both Blaine and Garrison can select from any table.

  • D. Neither Blaine nor Garrison can SELECT ANY TABLE.

A1:

Answer C is correct; both Blaine and Garrison can still select from any table in the database. Answers A and B are incorrect; revoking the SELECT ANY TABLE WITH ADMIN OPTION from Haylee won't revoke the privilege from one of the people that she granted it to but not the other. Answer D is incorrect because it is a system privilege. Revoking the privilege from Haylee won't have any effect on the privileges that she granted to other people.

2:

User Loren has granted Alex SELECT ON ALBUMS WITH GRANT OPTION. Alex has granted SELECT ON ALBUMS to Brittney and Brent. Loren decides that she no longer wants Alex to be able to grant other people access to her tables and revokes her privileges. What does this do to the privileges of Brittney and Brent?

  • A. Both Brittney and Brent can still select information from the albums table.

  • B. Neither Brittney nor Brent can select information from the albums table.

  • C. Brittney can continue to select from the albums table, but Brent cannot.

  • D. Brent can continue to select from the albums table, but Brittney cannot.

A2:

Answer B is correct; neither Brittney nor Brent can any longer select from the albums table. WITH GRANT OPTION on a nonsystem privilege means that when the privilege is revoked from the initial user, those revokes cascade to all users to whom that user granted the privileges. Answer A is incorrect; SELECT on a specific table is not a system privilege and will therefore not follow the rules of the passed-on privilege remaining after the user WITH GRANT OPTION has had her privileges revoked. Answers C and D are incorrect because the revoke would not affect one user while leaving the other user unaffected.

3:

User Arthur logs on to an idle instance as a user with SYSOPER and attempts to start up the database in restricted mode. What is the effect of the STARTUP RESTRICT command in this case?

  • A. Database is started and opened normally.

  • B. Database is started and opened in restricted mode.

  • C. Database is not started at all; SYSOPER can't start the database.

  • D. There is no SYSOPER role.

A3:

Answer B is correct; SYSOPER has the permissions to start up the database in restricted mode. Answer A is incorrect; the database will be started in restricted mode, not normally. Answer C is incorrect; SYSOPER does have start database privileges. Answer D is incorrect; two roles created when the database is created are SYSDBA and SYSOPER.

4:

You need to determine what system privileges have been granted to user Bethany. Which of the following queries would help you with this determination?

  • A. SELECT PRIVILEGE FROM DBA_SYS_PRIVS where grantee = 'BETHANY';

  • B. SELECT PRIVILEGE FROM DBA_TAB_PRIVS where grantee = 'BETHANY';

  • C. SELECT PRIVILEGE FROM SESSION_PRIVS where grantee = 'BETHANY';

  • D. SELECT PRIVILEGE FROM DBA_COL_PRIVS where grantee = 'BETHANY';

A4:

Answer A is correct; DBA_SYS_PRIVS contains a list of all the system privileges that have been granted to user or to roles. Answer B is incorrect; DBA_TAB_PRIVS contains a list of all the grants on any objects in the database but not any information on system privileges. Answer C is incorrect; SESSION PRIVS contains a list of all the system privileges currently available to the given user. Answer D is incorrect; DBA_COL_PRIVS lists all the object column grants in the database.

5:

What command provides user Crystal with select rights to the address table in your schema?

  • A. GIVE SELECT ON ADDRESS TO CRYSTAL;

  • B. GRANT SELECT ON ADDRESS TABLE TO CRYSTAL;

  • C. GRANT SELECT ON ADDRESS TO CRYSTAL;

  • D. PROVIDE CRYSTAL WITH SELECT PRIVILEGE ON ADDRESS TABLE;

A5:

Answer C is correct; GRANT SELECT ON ADDRESS TO CRYSTAL is the way that you grant select privileges to one user when you are logged in as the owner of that table or as SYS, SYSTEM, or other user with SYSDBA privilege. Answer A is incorrect; GIVE is not a keyword used to provide privileges to a user. Answer B is incorrect; the keyword TABLE is not necessary and will cause an error. Answer D is incorrect; PROVIDE is not a keyword or command in Oracle.

6:

Select any dictionary privilege has been granted to public. User Vaughn runs the following query. What is the result? Select * from v$session

  • A. Query fails; SELECT ANY TABLE does not allow for the selecting of data dictionary views when O7_DICTIONARY_ACCESSIBILITY is set to false.

  • B. Query is successful because the O7_DICTIONARY_ACCESSIBILITY parameter is set to FALSE.

  • C. Query is successful because the user has SELECT ANY TABLE privilege.

  • D. Query is successful because SELECT ANY DICTIONARY granted to PUBLIC allows anyone to select from the data dictionary.

A6:

Answer D is correct; this query is successful because SELECT ANY DICTIONARY has been granted to PUBLIC. This means that everyone who logs in to the database can select data dictionary views. Answer A is incorrect; although SELECT ANY TABLE alone doesn't allow you to select from the data dictionary when O7_DICTIONARY_ACCESSIBILITY is set to false, the addition of SELECT ANY DICTIONARY privilege allows the query to complete successfully. Answer B is incorrect; O7_DICTIONARY_ACCESSIBILITY set to false alone causes the query to fail. Answer C is incorrect; SELECT ANY TABLE alone when O7_DICTIONARY_ACCESSIBILITY is set to false causes the query to fail.

7:

What is the command used to enable auditing on altering tables in the database?

  • A. AUDIT

  • B. AUD$

  • C. AUDIT_TRAIL

  • D. DBA_AUDIT_OBJECT

A7:

Answer A is correct; enabling auditing on this level can be accomplished with the AUDIT command. Answer B is incorrect; AUD$ is the table into which audit records are placed. Answer C is incorrect; AUDIT_TRAIL is the initialization parameter that allows for auditing in the database at all but is not a command. Answer D is incorrect; this is a data dictionary view generated for objects that are audited.

8:

Which of the following statements is true to enable auditing in the database?

  • A. To set up auditing in Oracle, the AUDIT_TRAIL initialization parameter must be set to DB or OS.

  • B. To set up auditing in Oracle, the BEGIN_AUDIT initialization parameter must be set to trUE.

  • C. To set up auditing in Oracle, the AUDIT_TRAIL initialization parameter must be set to NONE.

  • D. To set up auditing in Oracle, the AUDITING initialization parameter must be set to trUE.

A8:

Answer A is correct; AUDIT_TRAIL=DB or AUDIT_TRAIL=OS allows auditing to be enabled in the database. Answer B is incorrect; BEGIN_AUDIT is not a valid initialization parameter. Answer C is incorrect; AUDIT_TRAIL=NONE turns off auditing in your database. Answer D is incorrect; AUDITING is not an initialization parameter.

9:

You have gotten several emergency calls from users who are trying to connect to the database. The users state that the database won't let them connect and that the audit trail is full. What statements describe what is happening in your database? [choose all that apply]

  • A. The database is up and running.

  • B. The users have lost CREATE SESSION privilege.

  • C. The SYS.AUD$ table is full, and you are auditing sessions.

  • D. Operating system authentication is used, and the users have lost their authentication.

  • E. The database has crashed.

  • F. The network has gone down.

A9:

Answers A and C are correct. The database is up and running, but the SYS.AUD$ table has filled up, and you are auditing sessions. Answer B is incorrect; unless revoked, privileges don't just go away. Answer D is incorrect; there is no way to tell what kind of authentication is being used, but they would not get an error about the audit trail being full if something was wrong with the authentication. Answer E is incorrect; if the database was down, they would not be getting an auditing error. Answer F is incorrect; if the network was down, the users wouldn't be able to get to Oracle.

10:

Which privilege enables a user to create a foreign key relationship on another user's table?

  • A. CREATE INDEX

  • B. CREATE ANY INDEX

  • C. REFERENCES

  • D. CREATE ANY KEY

A10:

Answer C is correct; REFERENCES is the privilege that allows you to create foreign keys on another user's tables. Answer A is incorrect. There is no CREATE INDEX privilege; it is inferred by the CREATE TABLE privilege, but only in the owned schema. Answer B is incorrect; CREATE ANY INDEX won't allow a user to create a foreign key relationship. Answer D is incorrect; there is no CREATE ANY KEY privilege.


Chapter 18. Managing Roles

Terms you'll need to understand:

  • DBA_ROLES

  • DBA_ROLE_PRIVS

  • ROLE_ROLE_PRIVS

  • DBA_SYS_PRIVS

  • ROLE_SYS_PRIVS

  • ROLE_TAB_PRIVS

  • SESSION_ROLES

  • DEFAULT ROLE

  • SET ROLE

  • DBMS_SESSION.SET_ROLE

  • Grant

  • Revoke

  • Enable

  • Disable

Concepts you'll need to master:

  • Create roles.

  • Modify roles.

  • Control role availability.

  • Remove roles from users.

  • Use predefined rules.

  • Remove roles from the database.

  • Display role information from the data dictionary.

Finally, we come to the last topic that will likely appear on your OCP exammanaging roles. Roles are Oracle's way of lumping together many privileges to make maintaining users and their privileges simpler and more centralized. This chapter provides an overview of roles and the part that they play in a healthy database.

Oracle provides roles as a facility for easy and controlled management for privileges. Roles are named groups of related privileges granted either directly to users or to other roles.

Roles share many characteristics:

  • May be granted to and revoked from users with the same commands used to grant and revoke system privileges.

  • May be granted to any users.

  • May be granted to another role.

  • May not be granted to themselves.

  • May not in any way be circularly referential.

  • May consist of both system and object privileges.

  • May be enabled or disabled for each user of the granted role.

  • May require that passwords be used to enable.

  • Names must be unique among existing usernames and role names.

  • Are not owned by anyone and are not in any given schema.

  • Have their entire description stored in the data dictionary.

Roles provide easier privilege management because many privileges can be grouped together to meet specific business rules. Roles can be granted directly with Oracle commands, or can be granted manually by the DBA. Not only is managing roles easier, management is more dynamic than could be accomplished with simply granting and revoking privileges directly to individual users. This is true because if a privilege that has been granted to a role changes, the change is automatically carried out to all the users who share that role. With roles, it is easier to turn privileges on and off temporarily. Finally, roles help to improve performance in the database. This is because there are fewer privileges to verify during statement execution, and by using roles there are fewer grants to check in the data dictionary whenever a user tries to accomplish something in the database.


Creating and Modifying Roles

When you create a role, you use the CREATE ROLE statement. Further, you need to have the CREATE ROLE system privilege to be able create roles in the database. You can either create a role as NOT IDENTIFIED, IDENTIFIED EXTERNALLY, IDENTIFIED BY PASSWORD, GLOBALLY, or USING PACKAGE. The default is NOT IDENTIFIED.

The general command used to create a role is as follows:

CREATE ROLE rolename
[NOT IDENTIFIED | IDENTIFIED
{BY password | EXTERNALLY |GLOBALLY | USING package_name}]

The role name is the name that you assign to the role and must be unique among all existing role names and usernames in the database. If you are working in a database that uses a multibyte character set, Oracle strongly suggests that the role name contain at least one single-byte character to make the encrypted role name and password combination more secure.

The IDENTIFIED BY clause specifies how the user must be authenticated before the role is enabled for the specific user to whom it was granted. The different ways that identification can be specified, if NOT IDENTIFIED is not used or inferred, are as follows:

  • BY PASSWORD allows the role to be authenticated by the database based on a password.

  • EXTERNALLY allows the role to be authenticated by the operating system, network, or any other external source.

  • GLOBALLY allows the role to be authenticated by an enterprise directory service.

  • USING package_name allows you to authenticate the user role by an application using a specific package.

Examples of creating the developers role with each of these options are as follows:

CREATE ROLE developers;

CREATE ROLE developers IDENTIFIED BY programmer;

CREATE ROLE developers IDENTIFIED EXTERNALLY;

CREATE ROLE developers IDENTIFIED GLOBALLY;

CREATE ROLE developers IDENTIFIED USING sys.role_admin;

Roles, when created, have no privileges associated with them; they are simply a named shell through which you can assign privileges to groups of users centrally. You have to explicitly GRANT privileges to the role or GRANT one role to another.

You can alter the authorization method for a role; however, to do this, you have to have the ALTER ANY ROLE system privilege or have been granted the role WITH ADMIN OPTION.

Granting Privileges to Roles

For roles to be useful, they need to have been granted privileges. The same privileges granted to individual users can be granted to roles, as well.

System Privileges

To grant system privileges and roles to other users and to other roles, you use the GRANT statement. The following privileges are required:

  • To grant a system privilege to a role, the granting user must already have the same system privilege with the WITH ADMIN OPTION. Otherwise, the granting user must have the GRANT ANY PRIVILEGE privilege.

  • To grant an already existing role that contains a system privilege to a role, the user doing the grant must either have been granted the role to be granted WITH ADMIN OPTION or must have been granted the GRANT ANY ROLE system privilege.

Object Privileges

To grant object privileges to roles, at least one of the following must be true:

  • You own the object.

  • You possess the GRANT ANY OBJECT PRIVILEGE system privilege. This privilege permits you to grant and revoke privileges on behalf of the owner of the object.

  • The privilege that you are trying to grant must have been granted to you using WITH GRANT OPTION.

Column Privileges

You can grant INSERT, UPDATE, or REFERENCES privileges on any individual columns in a table to a role the same as you can to an individual user.

Application Roles

Application roles can only be enabled by authorized PL/SQL packages, and these roles are created with the USING package clause. Application developers do not need to secure a role by hard-coding passwords inside applications; rather, application roles can be used to specify which package is authorized to enable the role.

Now that we have created and modified roles, we need to start assigning them to users.


Granting Roles

Assigning roles to a user uses the same syntax as the command that is used to grant a system privilege to the user, regardless of what privileges are in the role.

The following command would grant the developer role to Amandya WITH ADMIN OPTION:

GRANT ROLE developer TO Amandya WITH ADMIN OPTION;

The user who creates the role is implicitly assigned WITH ADMIN OPTION. Any user who has been granted a role but has not been granted it WITH ADMIN OPTION requires the GRANT ANY ROLE system privileges to grant or revoke the role to and from other users.

The maximum number of database roles that any user can enable is set by the MAX_ENABLED_ROLES initialization parameter. MAX_ENABLED_ROLES can take on a range of values from 1 to 148, and it defaults to 20. Actual roles and subroles for a user can be MAX_ENABLED_ROLES + 2 (Public and the user's own role). A change to this parameter requires a database restart.

Default Roles

Any given user can be assigned many roles. A default role is a distinct subset of those roles automatically enabled whenever that user logs in. By default, all of a user's assigned roles are enabled whenever that user logs in without the need of a password. You can limit the default roles for a user with the ALTER USER command.

The DEFAULT ROLE clause can only apply to roles that have already been granted directly to a user with the GRANT statement, not to embedded roles that have been granted to other roles. The DEFAULT ROLE clause cannot be used to enable the following:

  • Roles that have not been granted to the user

  • Roles that have been granted to the user through other roles to which they have been granted

The following is an example of the generic form of the DEFAULT ROLE clause:

ALTER USER username DEFAULT ROLE
{role [,role, role... |ALL [EXCEPT role [,role, role ... ] |NONE }

ALL causes all the roles that have been granted to a user the default roles, except those listed in an EXCEPT clause.

EXCEPT indicates that the roles following the keyword should be excluded from being default roles.

NONE makes none of the granted roles the user default role.

If NONE has been used when setting the default role, the only privileges enabled when the user logs in are privileges that have been directly assigned to the user.

Because roles have to be granted before they can be default roles, you cannot use the DEFAULT ROLE with the CREATE USER command.


Controlling Availability of Roles

It is within your responsibility as DBA, often, to control the availability of roles to users under a variety of circumstances. This section addresses the issues and concerns about how you, as the DBA, can control the availability of user roles.


Removing Roles

Roles are removed from users and from other roles the same way that privileges are removed from users and from roles, through the REVOKE command as follows:

REVOKE developer FROM larry;

If you need to remove a role from the database rather than from the user, this is accomplished through the DROP ROLE command.

When you drop a role, Oracle automatically revokes that role from all users and roles to which it has been granted and then removes it from the database.

To drop the role (DROP ROLE rolename;) from the database, you need to have been granted the role WITH ADMIN OPTION or have the DROP ANY ROLE system privilege.

Several predefined roles come with the database when it is created. These roles are outlined in the following section.


Using Predefined Roles

The roles in this section are defined automatically when the database is created. Table 18.1 contains the predefined roles and their descriptions.

Table 18.1. Oracle 9i Provided Roles and Descriptions

Role

Description

CONNECT

Includes CREATE SESSION, ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE SEQUENCE, CREATE TABLE, CREATE SYNONYM, and CREATE VIEW.

RESOURCE

Includes CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, and UNLIMITED TABLESPACE.

DBA

Includes all the system privileges WITH ADMIN OPTION as well as UNLIMITED TABLESPACE.

EXP_FULL_DATABASE

Provides all the privileges required to perform full database exports and incremental database exports. Includes SELECT ANY TABLE, BACKUP ANY TABLE, EXECUTE ANY PROCEDURE, EXECUTE ANY TYPE, and ADMINISTER RESOURCE MANAGER system privileges. Includes INSERT, DELETE, and UPDATE on the tables SYS.INCVID, SYS.INCFIL, and SYS.INCEXP object privileges. Includes the following roles: EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE.

IMP_FULL_DATABASE

Provides the privileges necessary to perform full database imports. There is an extensive list of system privileges and the EXECUTE_CATALOG_ROLE and the SELECT_CATALOG_ROLE.

DELETE_CATALOG_ROLE

Allows user to DELETE from the SYS.AUD$ table.

EXECUTE_CATALOG_ROLE

Allows user to execute objects in the data dictionary.

SELECT_CATALOG_ROLE

Allows user to select objects in the data dictionary.

RECOVER_CATALOG_OWNER

Provides privileges for the owner of the recovery catalog (used by RMAN). Includes CREATE SESSION, ALTER SESSION, CREATE SYNONYM, CREATE VIEW, CREATE DATABASE LINK, CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE TRIGGER, and CREATE PROCEDURE.

HS_ADMIN_ROLE

Used to protect access to the Heterogeneous Services (Heterogeneous Services is necessary for accessing a non-Oracle database system, typically in a distributed database) data dictionary tables (grants SELECT) and packages (grants EXECUTE). This role is granted to the SELECT_CATALOG_ROLE and EXECUTE_CATALOG_ROLE so that users who have generic data dictionary access also can access the Heterogeneous Services data dictionary.

AQ_USER_ROLE

This role has been deprecated but kept mainly for Oracle 8i compatibility. It provides execute privilege on the DBMS_AQ and DBMS_AQIN packages.

AQ_ADMINISTRATOR_ROLE

This role provides privileges necessary to administer Advance Queuing. Includes ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, and MANAGE ANY QUEUE system privileges; SELECT privileges on AQ tables; and EXECUTE privileges on AQ packages object privileges.

SNMPAGENT

Primarily, Oracle Enterprise Manager and the Intelligent Agent use this role. Includes ANALYZE ANY and SELECT on several different views.

CONNECT, RESOURCE, and DBA roles are created by the database for backward compatibility.

Enabling and Disabling Roles

You can disable a role to revoke that role temporarily from a user. You can enable a role to grant it temporarily to a user.

You use the SET ROLE command to enable or disable roles and provide a password for those that require passwords to be enabled. Default roles are enabled at user login, but often there is a point where it becomes necessary for a user to take on another role after logging in.

For a role to be enabled or disabled, the user must first have been granted the role.

ALTER USER...DEFALUT ROLE can be used to indicate which roles will be enabled for a given user at login, and all others will be disabled.

Whenever a role is enabled, the user to whom the role is enabled can use the privileges that have been granted to the role. If a role is disabled, the user cannot use the privileges associated with the role until those privileges have been granted directly to the user outside the disabled role. Enabling, or disabling, a role lasts only for the duration of the current session. At the next session's login, the user's active role reverts to his default role.

The SET ROLE command can be used to enable or disable roles, as can the DBMS_SESSION.SET_ROLE procedure, and enabling can be done from any program or tool that allows PL/SQL commands (except from a stored procedure). Using these commands, you would enable all roles included in the statement and disable all not included. If a password is required to enable a role, that password must be included in the SET ROLE command to enable the role; a default role enabled at login does not require a password.

A role cannot be enabled from a stored procedure. This is true because the action could change the security domain and its set of privileges that allowed the procedure to be called in the first place. For this reason, roles need to be enabled and disabled in an anonymous block or in application procedures rather than within PL/SQL procedures.

If a stored procedure contains the SET ROLE command, an error is generated.

An example of enabling and disabling roles follows. The first command enables the developer role; the second command has the effect of disabling the developer role:

SET ROLE developer;

SET ROLE ALL EXCEPT developer;


Role Creation Guidelines

Because roles include privileges that are necessary to enable a user to perform a task, the role name is typically some derivation of the application task or job title (as in my developer example).

The following are general guidelines for creating roles:

  • Create roles for each application task.

  • The name of an application role should correspond to the task within the application (for example, GL_ACCOUNTING).

  • Assign the privileges necessary to perform the task to the application role.

  • Whenever you create a role for a type of user, the name of the role should correspond to the job title (for example, GL_CLERK or AP_CLERK).

  • Grant application roles to user roles.

  • Grant user roles to users.

  • Modify application roles by adding new required privileges.

Using Passwords with Roles

Authorizing a role using passwords adds an extra level of security to the enabling of the role. It may mean that a user has to deliberately think about the fact that she is taking the steps to change from one role to another. For example, instead of "just" doing the standard job associated with an accounting clerk (a role that might have read privileges to the payroll information), the user changes to the role of payroll clerk (a role that enables that user to write to the tables and issue payroll checks).

When a user enables the password-protected role, the user logs in to the program that has been provided with the password, and the user never has to know or enter that password. In this way, security can be protected, and the user can still perform the check-writing function.

And we find ourselves again at the data dictionary where we can locate information on anything.


Role Information in the Data Dictionary

To find information in the data dictionary concerning roles, the following views are beneficial:

  • DBA_ROLES provides information on all the roles that exist in the database.

  • DBA_ROLE_PRIVS provides information on all the roles granted to users and roles.

  • ROLE_ROLE_PRIVS provides information on all the system roles granted to roles.

  • DBA_SYS_PRIVS provides information on all the system privileges that have been granted to users and roles.

  • ROLE_SYS_PRIVS provides information on all the system privileges that have been granted to roles.

  • ROLE_TAB_PRIVS provides information on all the system object privileges that have been granted to roles.

  • SESSION_ROLES provides information on all the roles that the currently logged-in user has enabled.


Exam Prep Questions

1:

What information would you expect to find by querying the SESSION_ROLE view?

  • A. All the sessions in the database with their default roles

  • B. All roles granted to a session

  • C. Roles enabled for current user

  • D. All the roles currently active in the database

A1:

Answer C is correct; in this view, you find all the roles enabled for the currently logged-in user. Answer A is incorrect; no single view shows all the sessions in the database and their default roles. Answer B in incorrect; roles aren't granted to sessions. Answer D is incorrect; there is no single view that tells you all the roles active in the database.

2:

Which statements are true about a role? [select all that apply]

  • A. It is owned by DBA.

  • B. It is owned by the user who created it.

  • C. A role can be granted to itself.

  • D. It can either contain just object privileges or just system privileges but not both.

  • E. It can be granted to any user.

  • F. It can be granted to any role except itself.

  • G. It can be granted to itself if it is granted circularly.

A2:

Answers E and F are correct; a role can be granted to any user and to any role except to itself, even circularly (by means of inclusion in another role). Answers A and B are incorrect; no user owns a role. Answers C and G are incorrect; a role cannot ever be granted to itself either directly or indirectly through inclusion in another role. Answer D is incorrect; roles can combine system privileges and object privileges in the same role.

3:

What is the main reason to create a role?

  • A. To have named structures in the database to associate to users so that you can remember what those users do

  • B. So that you can group system privileges in one group and object privileges in another group so that you can grant them separately

  • C. So that users know what privileges they have

  • D. So that you can more easily grant, revoke, and manage the privileges that users have assigned to them

A3:

Answer D is correct; the main benefit to creating roles in the database is that you can more easily and centrally maintain privileges and the users to whom they are assigned. Answer A is incorrect; they are not built simply as a memory aid to map users to job descriptions. Answer B is incorrect; you can group all relevant privileges together in one role. Answer C is incorrect; users don't necessarily need to know what privileges have been granted to them.

4:

Which of the statements are true about a role that is password authenticated.

  • A. Passwords are mandatory for roles in Oracle.

  • B. Passwords are necessary to grant the role to the user.

  • C. Passwords are necessary to use the role.

  • D. Passwords are necessary to create the role.

A4:

Answer C is correct; when a role is password authenticated, it is necessary for the user to provide the password to use the role. Answer A is incorrect; passwords are optional for roles. Answer B is incorrect; you don't have to provide a password when you grant the role, only when the role is enabled by the user. Answer D is incorrect; you can provide a password for the role at creation time, but it is not necessary in order to create the role.

5:

Who has the ability to grant a role? [select all that apply]

  • A. The person who created the role

  • B. Users with SELECT ANY ROLE privilege

  • C. Users with GRANT ANY ROLE privilege

  • D. Users who have been granted the role WITH GRANT OPTION

  • E. Users who have been granted the role WITH ADMIN OPTION

A5:

Answers A, C, and E are correct. You can grant roles if you create the role, if you have been given the GRANT ANY ROLE system privilege, or if you have been granted the role WITH ADMIN OPTION. Answer B is incorrect; there is no SELECT ANY ROLE privilege, and if there were, it would not allow you to grant the role. Answer D is incorrect; the syntax for roles is the same as the syntax for system privileges, and WITH GRANT OPTION is an object privilege syntax.

6:

You create a role called developer and grant CREATE TABLE and SELECT ANY TABLE to that role. Then you grant the role to user Lynn. Lynn then logs in to the database. What is true about Lynn's ability to manipulate tables in the database?

  • A. She can create and select from tables immediately after she logs in.

  • B. She can create and select from tables after she logs out and back in.

  • C. She has to have developer deliberately set as her default role before she can manipulate tables.

  • D. She has to have the CREATE TABLE and SELECT ANY TABLE granted to her directly before she can manipulate tables.

A6:

Answer A is correct; because the role has been granted to Lynn before she logged in, as soon as she logs in she will be able to access those privileges. Answer B is incorrect; there is no need to log out for her to use the role's privilegesit was enabled when she logged in. Answer C is incorrect; unless otherwise specified, all roles are hers by default. Answer D is incorrect; the point of roles is so that you don't have to directly grant privileges to every user.

7:

What is the effect of the following statement?

ALTER USER lonny DEFAULT ROLE ALL;

  • A. Lonny has the ALL role set as his default role.

  • B. Lonny has all defined roles in the database set as his default roles.

  • C. Lonny has all of his granted roles set as his default roles.

  • D. The statement generates an error.

A7:

Answer C is correct; the ALL keyword means that all Lonny's granted roles become default roles. Answer A is incorrect; ALL is a keyword, not the name of a role. Answer B is incorrect; a user can have a role made default only if that role has been assigned to the user. Answer D is incorrect; the statement is syntactically correct.

8:

What is the effect of the following command?

DELETE ROLE developer;

[select all that apply]

  • A. The role developer is removed from all users to whom it has been granted.

  • B. The role developer is removed from the database.

  • C. The role developer is removed only from the data dictionary.

  • D. The statement creates an error.

A8:

Answer D is correct; the syntax to remove the role from the database is DROP ROLE, not DELETE ROLE. Answers A and B would be correct if the DROP ROLE command were issued but are incorrect because the DELETE keyword is used. Answer C is incorrect; nothing removes the role from the data dictionary and leaves it in the database.

9:

Which predefined role is useful for database administrators because it has all the administrative privileges needed to maintain the entire database?

  • A. DBA

  • B. SYSTEM

  • C. SYSOPER

  • D. RESOURCE

A9:

Answer A is correct; DBA is the role that gives a DBA all the privileges needed to maintain the database. Answer B is incorrect; SYSTEM is a username to which DBA has been granted. Answer C is incorrect; SYSOPER does not have all the needed privileges to maintain the database. Answer D is incorrect; RESOURCE has many privileges but not enough to maintain the database.

10:

To determine which roles are available in the database, use the __________ view, and to determine which system privileges have been granted to a role, use the ___________ view.

  • A. DBA_ROLES, DBA_SYS_PRIVS

  • B. DBA_ROLES, DBA_SYSTEM_PRIVS

  • C. SESSION_ROLES, DBA_SYS_PRIVS

  • D. DBA_ROLES, DBA_TAB_PRIVS

A10:

Answer A is correct; DBA_ROLES is used for determining the available roles in the database, and the DBA_SYS_PRIVS view is used to determine which of them have system privileges. Answer B is incorrect; DBA_SYSTEM_PRIVS is not a view in the database. Answer C is incorrect; SESSION_ROLES tells you only the roles assigned to the currently logged-in user. Answer D is incorrect; DBA_TAB_PRIVS tells you the object privileges assigned to roles, not system privileges.


Chapter 19. Practice Exam 1

1:

At what point does the CKPT process write data blocks to the datafiles? [select all that apply]

  • A. Whenever LOG_CHECKPOINT_INTERVAL parameter tells it to.

  • B. Whenever LOG_CHECKPOINT_TIMEOUT tells it to.

  • C. Whenever there is a log switch.

  • D. CKPT doesn't write anything out to files; it tells the other processes to do that.

2:

What should you not do if your database creation script fails?

  • A. Check the SQL syntax.

  • B. Make sure that there is sufficient space in the file system, directory, or drive.

  • C. Rerun the script immediately.

  • D. Delete existing files.

3:

What is the p.password in the following role creation statement?

CREATE ROLE accountant IDENTIFIED USING p.password;

  • A. The password for the role

  • B. The procedure to authenticate the role

  • C. The procedure making the role the default role

  • D. None of the above

4:

Which of the following statements is not true concerning spfiles?

  • A. You can manually edit the spfile with any text editor.

  • B. Many of the values in the spfile can be altered dynamically during the period when the database is up.

  • C.spfiles are binary files maintained by Oracle.

  • D. The initialization parameters in the spfile are persistent between a database shutdown and a database startup.

5:

Which of the following is a requirement for online redefinition of a table?

  • A. Not null

  • B. Check constraint

  • C. Unique constraint

  • D. Primary key

6:

What is the first step you have to take when specifying a Database Resource Manager solution?

  • A. Create a resource plan.

  • B. Create plan directives.

  • C. Create a pending area.

  • D. Create a consumer group.

7:

Which of the following actions are permitted on an external table? [select all that apply]

  • A. Select

  • B. Insert

  • C. Update

  • D. Delete

  • E. Create Index

8:

Which of the following statements must be true for a database to use automatic segment space management?

  • A. In Oracle 9i, all space is automatically managed so nothing special must be done.

  • B. The segment management clause must be specified on the CREATE TABLE command with no additional requirements necessary.

  • C. The segment management clause is specified with the CREATE TABLESPACE command, and the tablespace has to be created as dictionary managed.

  • D. The segment management clause is specified with the CREATE TABLESPACE command, and the tablespace has to be created as locally managed.

9:

You have decided to use password file authentication and are using the password file utility to create the file as follows:

$orapwd file=$ORACLE_HOME/dbs/orapwMYDB
password=mypassword entries=15

Your REMOTE_LOGIN_PASSWORDFILE initialization parameter is set to NONE, and you have created a user as follows:

CREATE USER adam IDENTIFIED BY angelboy;
GRANT sysdba TO adam;

Your user adam attempts to connect to the database with the following command:

connect adam/angleboy as sysdba;

Why did this connection fail?

  • A. adam was not granted DBA role.

  • B. REMOTE_LOGON_PASSWORDFILE was set to NONE instead of EXCLUSIVE.

  • C. The password file should have been created in a different directory.

  • D. adam used the wrong password to connect as SYSDBA; it should have been mypassword.

10:

Amandya has created the SOCCER_STATS table. She now wants to find out the following information about the table:

The size of the initial extent allocated to the SOCCER_STATS segment

The current total number of extents allocated to the SOCCER_STATS segment

From which data dictionary view or views would you find this information? [select all that apply]

  • A. USER_EXTENTS

  • B. USER_SEGMENTS

  • C. USER_OBJECTS

  • D. USER_OBJECT_SIZE

  • E. USER_OBJECT_SIZE and USER_EXTENTS

  • F. USER_OBJECT_SIZE and USER_SEGMENTS

11:

Evaluate the following SQL:

CREATE USER alice IDENTIFIED BY madre;
GRANT CREATE ANY MATERIALIZED VIEW,
CREATE ANY DIMENSION,
DROP ANY DIMENSION
QUERY REWRITE
GLOBAL QUERY REWRITE
TO myrole WITH ADMIN OPTION;
GRANT myrole TO alice WITH ADMIN OPTION;

Which three actions can the user alice perform? [choose three]

  • A. Select from a table.

  • B. Create and drop a materialized view.

  • C. Alter a materialized view that you created.

  • D. Connect to the database.

  • E. Enable the role and exercise any privileges in the role's privilege domain.

  • F. Grant and revoke the role to and from other users.

12:

What two tools can be used for starting up and shutting down the Oracle instance and database? [select two]

  • A. SQL*Plus

  • B. Server Manager

  • C. Enterprise Manager

  • D. PL/SQL

13:

You are administering a database that currently has one control file. You decide that three control files would provide you with better protection against a single point of failure. To accomplish this, you need to modify the SPFILE so that it points to the locations of all three control files. You receive the message "system altered" after you have executed the CREATE CONTROLFILE command. You shut down the database and copy the single original control file to the new names and locations with operating system commands. On startup you receive the error ORA-00205: Error in identifying control file. You look in the alert log and determine that you inadvertently messed up the path for the control file.

What steps are required to resolve the problem and get the database to start?

  • A.

    1.
    Connect as SYSDBA.

    2.
    Shut down the database.

    3.
    Start the database in NOMOUNT mode.

    4.
    Use the ALTER SYSTEM SET CONTROL_FILES command to correct the error.

    5.
    Shut down the database.

    6.
    Start the database.

  • B.

    1.
    Connect as SYSDBA.

    2.
    Shut down the database.

    3.
    Start the database in MOUNT mode.

    4.
    Remove the SPFILE by using an OS command.

    5.
    Re-create the SPFILE from the PFILE by issuing the CREATE SPFILE FROM PFILE command.

    6.
    Use the ALTER SYSTEM SET CONTROL_FILES command to correct the error.

    7.
    Start the database.

  • C.

    1.
    Connect as SYSDBA.

    2.
    Shut down the database.

    3.
    Remove the control files using the OS command.

    4.
    Start the database in NOMOUNT mode.

    5.
    Remove the SPFILE by using an OS command.

    6.
    Re-create the SPFILE from the PFILE using the CREATE SPFILE FROM PFILE command.

    7.
    Use the ALTER SYSTEM SET CONTROL_FILES command to redefine the control files pointing to the locations correctly.

    8.
    Shut down the database.

    9.
    Start the database.

  • D.

    1.
    Connect as SYSDBA.

    2.
    Shut down the database.

    3.
    Copy the control files to the new location with OS commands.

    4.
    Start the database.

14:

Which type of index does this syntax create?

CREATE INDEX adam.merit_badge_index
ON adam.merit_badge (badge_name)
TABLESPACE adam_indx;

  • A. Bitmap

  • B. B-tree

  • C. Partitioned

  • D. Reverse key

15:

Which two actions cause a log switch? [choose two]

  • A. The current online redo log group is filled.

  • B. The ALTER SYSTEM SWITCH LOGFILE command is issued.

  • C. The instance is shut down.

  • D. A transaction completes.

  • E. The instance is started.

16:

The users adam and amandya have left the company. Company policy states that they can no longer have any access to the database. However, both have created vital structures in the database. You need to make sure that the objects they created in the database remain available. What do you need to do?

  • A. Revoke the CREATE SESSION privilege from the adam and amandya users.

  • B. Drop the adam and amandya users from the database with the CASCADE option.

  • C. Delete the adam and amandya users and revoke the CREATE SESSION privilege.

  • D. Delete the adam and amandya users from the database by using the DROP USER command.

17:

You examine your alert log file and notice that errors are being generated from a SQL*Plus session. Which of the following files would be your first and best option for providing more information about the nature of the problem?

  • A. Control file

  • B. User trace files

  • C. Background trace files

  • D. Core trace files

  • E. Initialization parameter files

18:

Which data dictionary view would you use from which to get a list of object privileges for all database users?

  • A. DBA_TAB_PRIVS

  • B. ALL_TAB_PRIVS

  • C. USER_TAB_PRIVS

  • D. ALL_TAB_PRIVS_MADE

19:

You need to create an index on the SOFTWARE_ID column of the SOFTWARE_INVENTORY table.

The index has the following requirements:

  1. The index will be called SOFTWARE_PK.

  2. The index should be sorted in ascending order.

  3. The index should be created in the SOFTWARE_INDEX tablespace, which is a dictionary managed tablespace.

  4. All extents of the index should be 1MB in size.

  5. The index should be unique.

  6. No redo information should be generated when the index is created.

  7. There should be 20% allocated to additions to the index.

Which command creates the index and meets all the requirements?

  • A.

    CREATE UNIQUE INDEX software_pk ON software_inventory (software_id)
TABLESPACE software_index
PCTFREE 20
STORAGE (INITIAL lm NEXT lm PCTINCREASE 0);

  • B.

    CREATE UNIQUE INDEX software_pk ON software_inventory (software_id)
TABLESPACE software_index
PCTFREE 20
STORAGE (INITIAL 1m NEXT 1m PCTINCREASE 0)
NOLOGGING;

  • C.

    CREATE UNIQUE INDEX software_pk ON software_inventory (software_id)
TABLESPACE software_index
PCTUSED 80
STORAGE (INITIAL lm NEXT lm PCTINCREASE 0)
NOLOGGING;

  • D.

    CREATE UNIQUE INDEX software_pk ON software_inventory (software_id)
TABLESPACE software_index
PCTUSED 80
STORAGE (INITIAL lm NEXT lm PCTINCREASE 0);

20:

Which statement about the shared pool is true?

  • A. The shared pool cannot be dynamically resized in Oracle 9i.

  • B. The shared pool contains only fixed structures.

  • C. The shared pool consists entirely of the library cache and buffer cache.

  • D. The shared pool stores the most recently executed SQL statements and the most recently accessed data definitions.

21:

Which type of file is part of the Oracle database?

  • A. Database creation script file

  • B. Password file

  • C. Control file

  • D. Parameter file

  • E. Archived log file

22:

User mike issues the following command:

UPDATE merit_badge
SET id=200
WHERE id=1

Then user steve issues this command:

UPDATE merit_badge
SET id=300
WHERE id=1

Steve informs you that his UPDATE statement seems to be hung. How could you resolve the current issues so that Steve can continue working?

  • A. No action is required; Steve is just being impatient.

  • B. Ask Steve to abort the statement.

  • C. Ask Mike to commit the transaction.

  • D. Ask Steve to commit the transaction.

23:

Which statement about an Oracle instance is true?

  • A. The redo log buffer is not a part of the shared memory area of an Oracle instance.

  • B. Multiple Oracle instances can execute on the same computer with each instance accessing its own physical database.

  • C. An Oracle instance is a combination of memory structures, background processes, and user processes.

  • D. In a shared server environment, the memory structure component of an instance consists of a single SGA and a single PGA.

24:

Which of the following statements are true about the use of online redo log files? [select all that apply]

  • A. Redo log files are used only for recovery.

  • B. Each redo log within a group is called a member.

  • C. Redo log files are organized into a minimum of three groups.

  • D. An Oracle database requires at least three online redo log members.

  • E. Redo log files provide the database with a read consistency method.

  • F. Redo log files provide the means to redo transactions in the event of an instance failure.

25:

Which data dictionary view would you use to get a listing of all database users and their default settings?

  • A. ALL_USERS

  • B. USERS_USERS

  • C. DBA_USERS

  • D. V$USERS

26:

Consider this SQL statement:

UPDATE employees SET first_name = 'Junior'
WHERE emp_id = 100;
COMMIT;

What happens when this user issues the COMMIT in the preceding SQL statement?

  • A. Dirty buffers in the database buffer cache are flushed.

  • B. The server process places the commit record in the redo log buffer.

  • C. LGWR writes the redo log buffer entries to the redo log files and data files.

  • D. The user manually notifies the server processes that the transaction is complete.

  • E. The user process automatically notifies the server processes that the transaction is complete.

27:

Examine the following statements:

  1. MOUNT mounts the database for certain DBA activities but does not provide user access to the database.

  2. The NOMOUNT command creates only the data buffers but does not provide access to the database.

  3. The OPEN command enables users to access the database.

  4. The STARTUP command starts an instance.

Which statements are true [select all that apply]

  • A. 1

  • B. 2

  • C. 3

  • D. 4

  • E. None are true

28:

You are using DBCA and find that you need to change some of the custom templates that you have stored. What option from the first screen would you use to accomplish this?

  • A. Create database

  • B. Manage templates

  • C. Configure options in database

  • D. Change all templates

29:

Your database contains a locally managed uniform sized tablespace with automatic segment-space management. These tablespaces contain only tables.

Currently, the uniform size defined for the tablespaces is 512KB.

Because several of the tables have become very large, you determine that your configuration must change to improve performance and that now those very large tables must reside in tablespaces that are locally managed, with uniform size of 5MB and automatic segment-space management.

What must you do to meet the new requirements?

  • A. The new requirements cannot be met without re-creating the database.

  • B. The control file needs to be re-created with the new, corrected settings.

  • C. Use the ALTER TABLESPACE command for the current tablespaces to increase the uniform size.

  • D. Create a new tablespace with correct settings and then move the tables in question into the new tablespace.

30:

You have two UNDO tablespaces defined for your database. The instance is currently using the undo tablespace named UNDO_1. You issue the following command to switch to the other UNDO tablespace, UNDOTBS_2. The switch occurs while there are still transactions using UNDOTBS_1:

ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_2

What is the result of this statement under these conditions? [choose all that apply]

  • A. All new transactions will be assigned to UNDOTBS_2.

  • B. Current transactions will be switched to the UNDOTBS_2 tablespace.

  • C. The switch to UNDOTBS_2 fails, and an error message is returned.

  • D. The UNDOTBS_1 undo tablespace enters into a PENDING OFFLINE status while there are still active transactions accessing it.

  • E. The switch to UNDOTBS_2 does not take place until all transactions in UNDOTBS_1 are completed.

  • F. You can't have two UNDO tablespaces defined for your database.

31:

Extents are a logical collection of contiguous _________________.

  • A. Segments

  • B. Database blocks

  • C. Tablespaces

  • D. Operating system blocks

32:

You just created the following roles using the statements shown:

CREATE ROLE ar_clerk;
CREATE ROLE ap_clerk IDENTIFIED BY payables;
CREATE ROLE gl_clerk IDENTIFIED EXTERNALLY;
CREATE ROLE genuser IDENTIFIED GLOBALLY;
CREATE ROLE developer IDENTIFIED USING p.pass;

Which statement indicates that a user must be authorized to use the role by the enterprise directory service before the role is enabled?

  • A. CREATE ROLE ar_clerk;

  • B. CREATE ROLE genuser IDENTIFIED GLOBALLY;

  • C. CREATE ROLE ap_clerk IDENTIFIED BY payables;

  • D. CREATE ROLE developer IDENTIFIED USING p.pass;

  • E. CREATE ROLE gl_clerk IDENTIFIED EXTERNALLY;

33:

The accounting controller for your organization has complained that the report she runs monthly takes too long to run. You look at the query that the report runs and determine that the report would run faster if there was an index on the AP_ENTRY_MONTH column of the AP_TRANS table. The AP_TRANS table has about 5 million rows currently, and around 100 new rows are added every month. Old records are never deleted from the table.

The AP_ENTRY_MONTH column is defined as a VARCHAR2(15) field. There are only 12 possible months, and they change very infrequently.

Which type of index would be best for this column?

  • A. B-tree

  • B. Bitmap

  • C. Reverse key

  • D. Function-based

34:

You need to create an index on the MERIT_BADGES_EARNED table. It contains 5 million rows of data, and the key columns have low cardinality. The queries generated against this table use a combination of multiple WHERE conditions involving the OR operator.

Which type of index would be best for this type of table?

  • A. Bitmap

  • B. Unique

  • C. Partitioned

  • D. Reverse key

  • E. Single column

  • F. Function-based

35:

When is the SGA created in an Oracle instance?

  • A. When the database is created

  • B. When the instance is opened

  • C. When the user process is started

  • D. When a server process is started

36:

Which pair of words completes the following statement?

When issuing the STARTUP NOMOUNT command, the Oracle instance is _____________, and the Oracle database is ______________?

  • A. Started, not mounted

  • B. Started, mounted

  • C. Started, opened

  • D. Not started, not mounted

37:

For a tablespace created with automatic segment-space management, where is rollback information maintained?

  • A. In the extent

  • B. In the control file

  • C. In the data dictionary

  • D. In the undo tablespace

38:

Which two conditions must exist with respect to the directories you specify in the DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n initialization parameters when using Oracle managed files? [choose two]

  • A. The directories must already exist.

  • B. The directories must not contain any other files.

  • C. The directories must be created as subdirecties of the $ORACLE_HOME directory.

  • D. The directories must have appropriate permissions that allow Oracle to create files in them.

39:

Your organization finds that more stringent user access is required, and those requirements have been issued. You need to do the following tasks for the user lonny:

  1. Change user authentication to external authentication.

  2. Revoke the user's ability to create objects in the test tablespace.

  3. Add a new default and temporary tablespace and set a quota of unlimited.

  4. Assign the user to the CLERK profile.

Which statement meets the requirements?

  • A.

    ALTER USER lonny
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp01
QUOTA UNLIMITED ON users
QUOTA 0 ON test_ts
GRANT clerk TO lonny;

  • B.

    ALTER USER lonny
IDENTIFIED by dion
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp01
QUOTA UNLIMITED ON users
QUOTA 0 ON test
PROFILE clerk;

  • C.

    ALTER USER lonny
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp01
QUOTA UNLIMITED ON users
QUOTA 0 ON test
PROFILE clerk;

  • D.

    ALTER USER lonny
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp01
QUOTA UNLIMITED ON users
QUOTA 0 ON test;
GRANT clerk to lonny;

40:

For which constraints will indexes automatically be created when the constraint is added? [choose all that apply]

  • A. Check

  • B. Unique

  • C. Not null

  • D. Primary key

  • E. Foreign key

41:

You are creating a new database.

You do not want users to use the SYSTEM tablespace for sorting operations.

What should you do when you issue the CREATE DATABASE statement to prevent this?

  • A. Create an undo tablespace.

  • B. Create a default temporary tablespace.

  • C. Create a tablespace with the UNDO keyword.

  • D. Create a tablespace with the TEMPORARY keyword.

42:

Select the memory structure or structures that would be used to store the parse information and actual value of the bind variable ID for the following set of commands:

VARIABLE id NUMBER;
BEGIN
:id:=1;
END;

  • A. PGA only

  • B. Row cache and PGA

  • C. PGA and library cache

  • D. Shared pool only

  • E. Library cache and buffer cache

43:

Which background process performs a checkpoint in the database causing the writing of modified blocks from the database buffer cache in the SGA to the data files?

  • A. LGWR

  • B. SMON

  • C. DBWn

  • D. CKPT

  • E. PMON

44:

A network error unexpectedly terminated a user's database session.

Which `two events occur in this scenario? [choose two]

  • A. Checkpoint occurs.

  • B. A fast commit occurs.

  • C. RECO performs the session recovery.

  • D. PMON rolls back the user's current transaction.

  • E. SMON rolls back the user's current transaction.

  • F. SMON frees the system resources reserved for the user session.

  • G. PMON releases the table and row locks held by the user session.

45:

A table is stored in a dictionary managed tablespace.

Which two columns are required from DBA_TABLES to determine the size of the next extent when it extends? [choose two]

  • A. BLOCKS

  • B. PCT_FREE

  • C. NEXT_EXTENT

  • D. PCT_INCREASE

  • E. INITIAL_EXTENT

46:

When is the SGA created in an Oracle database?

  • A. When the database is created

  • B. When the instance is started

  • C. When the database is mounted

  • D. When the database is opened

  • E. When the SGA server process is started

47:

Which type of table is usually created to enable the building of highly scalable applications and is particularly useful for large tables that can be queried or manipulated using several processes concurrently?

  • A. Regular table

  • B. Clustered table

  • C. Partitioned table

  • D. Index-organized table

48:

Based on the following profile limits, if a user attempts to log in and fails after three tries, how long must the user wait before attempting to log in again?

ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 60
PASSWORD_GRACE_TIME 10
PASSWORD_REUSE_TIME 3600
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1/1440
PASSWORD_VERIFY_FUNCTION verify_function;

  • A. 1 minute

  • B. 5 minutes

  • C. 10 minutes

  • D. 14 minutes

  • E. 18 minutes

  • F. 60 minutes

49:

You have a database with the DB_NAME set to TEST and ORACLE_SID set to TEST.

These files are in the default locations for the initialization files:

  • init.ora

  • initTEST.ora

  • spfile.ora

  • spfileTEST.ora

The database is started with this command:

SQL> startup

Which initialization files does the Oracle Server attempt to read, and in which order?

  • A. init.ora, initTEST.ora, spfileTEST.ora

  • B. spfile.ora, spfileTEST.ora, initTEST.ora

  • C. spfileTEST.ora, spfile.ora, initTEST.ora

  • D. initTEST.ora, spfileTEST.ora, spfile.ora

50:

Which constraint state prevents new data that violates the constraint from being entered but allows invalid data to exist in the table?

  • A. ENABLE NOVALIDATE

  • B. DISABLE NOVALIDATE

  • C. ENABLE VALIDATE

  • D. DISABLE VALIDATE

51:

Which three statements are true about the Oracle database storage structure? [choose three]

  • A. A data block is a logical structure.

  • B. A single data file can belong to multiple tablespaces.

  • C. When a segment is created, it consists of at least one extent.

  • D. The data blocks of an extent may or may not belong to the same file.

  • E. A tablespace can consist of multiple data files, each from a separate disk.

  • F. Within a tablespace, a segment cannot include extents from more than one file.

52:

Which steps should you take to gather information about checkpoints?

  • A. Set the LOG_CHECKPOINTS_TO_ALERT initialization parameter to trUE. Monitor the alert log file.

  • B. Set the LOG_CHECKPOINT_TIMEOUT parameter. Force a checkpoint by using the FAST_START_MTTR_TARGET parameter. Then begin to monitor the alert log file.

  • C. Set the LOG_CHECKPOINT_TIMEOUT parameter. Force a log switch by using the command ALTER SYSTEM LOGSWITCH. Force a checkpoint by using the command ALTER SYSTEM CHECKPOINT. Monitor the alert log file.

  • D. Set the FAST_START_MTTR_TARGET parameter to trUE. Force a checkpoint by using the command ALTER SYSTEM CHECKPOINT. Monitor the alert log file.

53:

The DBA can structure an Oracle database so that it will maintain backup copies of online redo log files to avoid losing database information. Which three are true regarding the structure of online redo log files? [choose three]

  • A. Each online redo log file in a group is called a member.

  • B. Each member in a group has a unique log sequence number.

  • C. A set of identical copies of online redo log files is called an online redo log group.

  • D. The Oracle Server needs a minimum of three online redo log file groups for the normal operation of a database.

  • E. The current log sequence number of a redo log file is stored in the control file and in the header of all data files.

  • F. The LGWR background process concurrently writes the same information to all online and archived redo log files in a group.

54:

Which is a complete list of the logical components of the Oracle database in order of size?

  • A. Tablespaces, segments, extents, and data files

  • B. Tablespaces, segments, extents, and Oracle blocks

  • C. Tablespaces, database, segments, extents, and data files

  • D. Tablespaces, database, segments, extents, and Oracle blocks

  • E. Tablespaces, segments, extents, data files, and Oracle blocks

55:

A table can be dropped if it is no longer needed.

Which three statements are true about dropping a table? [choose three]

  • A. All synonyms for a dropped table are automatically deleted.

  • B. When a table is dropped, the extents used by the table are released.

  • C. Dropping a table removes the table definition from the data dictionary.

  • D. Indexes and triggers associated with the table are not dropped but marked INVALID.

  • E. The CASCADE CONSTRAINTS option is necessary if the table being dropped is the parent table in a foreign key relationship.

56:

An INSERT statement failed and is rolled back. What concept does this demonstrate?

  • A. Insert recovery

  • B. Read consistency

  • C. Transaction recovery

  • D. Transaction rollback

57:

You used the password file utility to create a password file as follows:

$orapwd file=$ORACLE_HOME/dbs/orapwMYDB01
password=orapass entries=50

You created a user and granted only the SYSDBA privilege to that user as follows:

CREATE USER angela
IDENTIFIED BY leighlynn;
GRANT sysdba TO angela;

The user attempts to connect to the database as follows:

connect angela/orapass as sysdba;

Why does the connection fail?

  • A. The DBA privilege had not been granted to dba_user.

  • B. The SYSOPER privilege had not been granted to dba_user.

  • C. The user did not provide the password leighlynn to connect as SYSDBA.

  • D. The information about dba_user has not been stored in the password file.

58:

There are three ways to specify National Language Support parameters:

  1. Initialization parameters

  2. Environment variables

  3. ALTER SESSION parameters

Match each of these with their appropriate definitions.

  • A.

    1. Parameters on the client side specify locale-dependent behavior overriding the defaults set for the server.

    2. Parameters on the server side specify the default server environment.

    3. Parameters override the default set for the session or the server.

  • B.

    1. Parameters on the server side specify the default server environment.

    2. Parameters on the client side specify locale-dependent behavior overriding the defaults set for the server.

    3. Parameters override the default set for the session or the server.

  • C.

    1. Parameters on the server side specify the default server environment.

    2. Parameters override the default set for the session or the server.

    3. Parameters on the client side specify locale-dependent behavior overriding the defaults set for the server.

  • D.

    1. Parameters on the client side specify locale-dependent behavior overriding the defaults set for the server.

    2. Parameters override the default set for the session or the server.

    3. Parameters on the server side specify the default server environment

59:

Which of the following are valid places where initialization parameters can be found for use when the database is starting up? [select all that apply]

  • A. control01.ctl

  • B. initmydb1.ora

  • C. system01.dbf

  • D. spfilemydb1.ora

60:

Which is true when considering the number of indexes to create on a table?

  • A. Every column that is updated requires an index.

  • B. No column that is updated should have an index.

  • C. Every column that is queried is a candidate for an index.

  • D. Columns that are part of a WHERE clause are candidates for an index.

  • E. On tables used in a data warehouse application, there should be no indexes.


Chapter 20. Exam 1 Answers

1. D

2. C

3. B

4. A

5. D

6. C

7. A

8. D

9. B

10. B

11. B, E, F

12. A, C

13. A

14. B

15. A, B

16. A

17. B

18. A

19. B

20. D

21. C

22. C

23. B

24. A, B, F

25. C

26. B

27. A, C

28. B

29. D

30. A, D

31. B

32. B

33. B

34. A

35. B

36. A

37. D

38. A, D

39. C

40. B, D

41. B

42. C

43. C

44. D, G

45. C, D

46. B

47. C

48. A

49. C

50. A

51. A, C, E

52. B

53. A, C, E

54. B

55. B, C, E

56. D

57. C

58. B

59. B, D

60. D

A1: | Answer D is the only correct answer. Checkpoint doesn't actually write anything out to files; it causes the DBW n process to write the data from the database buffer cache out to the database files. Answer A is incorrect because LOG_CHECKPOINT_INTERVAL tells CKPT how often in terms of volume to cause a checkpoint, but it does not ever write anything. Answer B is incorrect because LOG_CHECKPOINT_TIMEOUT tells CKPT how often in terms of periods of time in seconds to cause a checkpoint, but it does not ever write anything. Answer C is incorrect because a log switch causes CKPT to occur, but it does not ever write anything.
A2: | Answer C is correct. Rerunning the script immediately won't resolve any issues and will likely present you with new ones that may cloud the original issue. Answer A should be done first; check to see whether you have syntax errors in your CREATE DATABASE script. Answer B should be done next; make sure that you have enough space in the place you are using for your files to house them. Answer D should be done right before you are ready to run the script again; leaving files out in the same location will likely cause your script to fail again.
A3: | Answer B is correct. p.password is the procedure used to authenticate the role. Answer A is incorrect; passwords cannot contain special characters such as periods. Answer C is incorrect; the default role isn't set at the role level but at the user level. Answer D is incorrect because answer B is indeed correct.
A4: | Answer A is correct; you cannot edit the SPFILE with a text editor. The SPFILE is a binary file that will no longer work if you edit it with a text editor. Answer B is incorrect; many of the values in the SPFILE can be altered dynamically during the time when the database is operational. Answer C is incorrect; the SPFILE is binary and is maintained by Oracle. Answer D is incorrect; the SPFILE is an initialization parameter file that houses initialization parameters that are persistent between shutdown and startup of the database.
A5: | Answer D is correct; for a table to be redefined online, it needs to have a primary key defined for it. Answer A is incorrect because although primary keys cannot be NULL, the table can have nullable columns. Answer B is incorrect; no table requires check constraints, and redefinition has no influence on this decision. Answer C is incorrect; although primary key infers uniqueness, a unique key is not the constraint required.
A6: | Answer C is correct; the first thing that you need to do when you define a Database Resource Manager solution for your database is to create a pending area. Answers A, B, and D are incorrect; you have to have a pending area to define a resource plan, a plan directive, or a consumer group.
A7: | Answer A is correct. The only action allowed on an external table is select. Answers B, C, D, and E are all incorrect. Only select is allowable on external tables. They are read-only tables. One of the drawbacks to external tables is that they are not indexable.
A8: | Answer D is correct; for automatic segment space management to work, the segment management clause needs to be specified with the CREATE TABLESPACE command, and the tablespace has to have been created locally managed. Answer A is incorrect; in Oracle 9i the default is still dictionary managed for all tablespaces. Answer B is incorrect; tablespaces are automatic space managed. This carries down to the table level, but a table cannot have a different space management clause than its tablespace. Answer C is incorrect; for a tablespace to be automatic space managed, it has to be locally managed, not dictionary managed.
A9: | Answer B is correct; to use the password file, the REMOTE_LOGON_PASSWORDFILE parameter has to be set to EXCLUSIVE if you want those to whom SYSDBA has been granted to be able to log in as sysdba using the password file. Answer A is incorrect; it is not necessary to be DBA. You have to be SYSDBA to use password files for authentication. Answer C is incorrect; it is irrelevant where the password file is created as long as it is available to Oracle. Answer D is incorrect; the user used the correct password to connect.
A10: | Answer B is correct; to determine the size of the initial extent and the total number of extents allocated to a given segment, you would query the USER_SEGMENTS view. Answer A is incorrect; USER_EXTENTS provides information on the segment name, partition, type of segment, tablespace in which it is located, and ID of the current extent. Answer C is incorrect; USER_OBJECTS provides information about the object, its type, its ID, and when it was created but not anything dealing with extents. Answer D is incorrect; USER_OBJECT_SIZE does not provide information in extents or provide extent sizing information. Answers E and F are incorrect because they include USER_OBJECT_SIZE.
A11: | Answers B, E, and F are correct; she can create a materialized view in any schema, she can enable the role and exercise any privileges in the role's privilege domain, and she can grant the role to and revoke the role from other users because she has been given WITH ADMIN OPTION. Answer A is incorrect because nothing in the statement provides the information that she can select from a table. Answer C is incorrect; just because she can create a materialized view does not mean that she can alter any materialized view other than those that she owns. Answer D is incorrect; nowhere does it indicate that she can connect or create a session in the database.
A12: | Answers A and C are correct; you can use SQL*Plus or Enterprise Manager to start up and shut down Oracle. Answer B, Server Manager, was a utility available in previous releases of Oracle but is no longer supported or available. Answer D, PL/SQL, is a procedural language used in Oracle, not a utility available through which you can start up or shut down a database.
A13: | Answer A is correct. First you connect as SYSDBA or as a user with SYSDBA role and shut down the database. Then you restart the database in NOMOUNT mode and alter the system state to point CONTROL_FILES to the correct location. Then shut down the database again and restart and open for operation. Answer B is incorrect because you would not open the database in MOUNT mode and then remove the SPFILE with an OS command. The file is being read by the instance, and if you read the answer carefully, you will see that there is no way to start an already running database. This would be a trick answer. Answer C is incorrect because you don't want to remove the SPFILE. You just want to correct where it is pointing. Answer D is incorrect because simply recopying won't help; the control files have already had their headers changed, and recopying the control file won't solve your problems.
A14: | Answer B is correct; this command would create a B-tree index. Answer A is incorrect; there are no keywords in the command (CREATE BITMAP INDEX) to indicate that it would be a bitmap index. Answer C is incorrect; there is no partitioning clause on the CREATE INDEX statement. Answer D is incorrect; nothing is included to indicate that the index should be reverse key; therefore, it will not be.
A15: | Answers A and B are correct. Either deliberately issuing the ALTER SYSTEM SWITCH LOGFILE command or when the current online redo log file is filled will cause a log switch. Answer C is incorrect; redo log files do not switch when the instances is shut down. Answer D is incorrect; redo log switches are not connected to transactions. Answer E is incorrect; starting the database will not automatically cause the redo logs to switch.
A16: | Answer A is correct; you need to REVOKE the CREATE SESSION privilege from the users to make sure that they can't log in to the database but to also allow the owned objects to remain in the database to be accessed by others. Answer B is incorrect; dropping the users also drops the objects belonging to those users. Answer C is incorrect; again, dropping the users would drop the objects as well, and after you drop the users, you can no longer revoke privileges from them. Answer D is incorrect because not only will removing the users remove the objects, the command would be drop, not delete.
A17: | Answer B is correct; errors generated by SQL*Plus sessions would typically go into the user trace files found in the udump directory. Answer A is incorrect because errors would never be found in the control file. Answer C is incorrect because SQL*Plus sessions are user sessions and would typically not create background trace files. Those are created by server processes in the instance. Answer D is incorrect; core trace files, or core dump files, are generated when the server core dumps but not when SQL*Plus generates errors. Answer E is incorrect because errors would never be generated in the initialization files.
A18: | Answer A is correct; DBA_TAB_PRIVS would give you an overview of what table privileges have been given to all database users. Answer B is incorrect; ALL_TAB_PRIVS would show you all the table privileges that the logged-in user has been granted. Answer C is incorrect; USER_TAB_PRIVS would show you all the privileges that the given user has on his or her own tables. Answer D is incorrect; ALL_TAB_PRIVS_MADE is not a valid data dictionary view.
A19: | Answer B is correct; this will not only create a unique index in the correct tablespace, it also will have the proper space management, will be dictionary managed, and will generate no redo information (NOLOGGING keyword). Answer A is incorrect; it will generate redo log entries. Answer C is incorrect; you need to specify the PCTFREE not PCTUSED. Answer D is incorrect; you need to specify PCTFREE not PCTUSED, and answer D will generate redo log entries.
A20: | Answer D is correct. The shared pool does store the most recently executed SQL statements and the most recently accessed data definitions. Answer A is incorrect; the shared pool is dynamically resized starting in Oracle 9i. Answer B is incorrect; the shared pool does not contain only fixed structures. Answer C is incorrect; the library cache and the buffer cache are not the only structures in the SGA.
A21: | Answer C is correct; the control file is a part of the database. Answer A is incorrect; the database creation script created the database but is not a part of the database. Answer B is incorrect; the password file is one of the auxiliary files to the database but is not a part of it. Answer D is incorrect; parameter files are required for the starting of the database but not a part of it. Answer E is incorrect; archive log files are auxiliary structures to the database not a part of the database.
A22: | Answer C is correct; you should contact Mike and request that he commit the current transactions. Answer A is incorrect; Mike has the records locked that Steve needs to access. Steve is not just being impatient. Answer B is not the answer; Steve should not have to abort his transaction. Answer D is incorrect; Steve is seeing hung systems already. Issuing a commit will not only not solve the current problem, it will also not work because the session is in effect locked.
A23: | Answer B is correct; multiple independent instances can coexist on the same physical server. Answer A is incorrect; the redo log buffers are a part of the shared memory area. Answer C is incorrect; user processes are not a part of the Oracle instance. Answer D is incorrect; you can have multiple PGAs in a shared server environment.
A24: | Answers A, B, and F are correct; the purpose of redo log files is to allow for elegant instance recovery in case of an instance failure, and the redo log group individual files are called members. Answer C is incorrect; you need a minimum of two groups. Answer D is incorrect; Oracle requires a minimum of two redo log groups, each only has to hold one file. Answer E is incorrect; UNDO ensures read consistency, not the redo log files.
A25: | Answer C is correct; the information required can be found in the DBA_USERS table. Answer A is incorrect; ALL_USERS only gives you a listing of each user in the database when they were created, and their user_id. Answer B is incorrect; USER_USERS shows you all the information needed except the profile. Answer D is incorrect; V$USERS is not a dynamic performance view.
A26: | Answer B is correct; under these circumstances, the server process places the commit record into the redo log buffer. Answer A is incorrect; COMMIT does not cause the database buffer cache to be flushed. Answer C is incorrect; log writer does not play a part in a COMMIT operation. Answer D is incorrect. Users do not have to notify anything of the COMMIT operation; Oracle handles that itself. Answer E is incorrect; Oracle handles the notification, not the user process.
A27: | Answers A and C are correct; MOUNT mounts the database for certain DBA activities but does not provide user access to the database, and the OPEN command enables users to access the database. Answer B is incorrect; NOMOUNT does not create the buffers. Answer D is incorrect; STARTUP starts the instance and the database. Answer E is incorrect; because A and C are correct.
A28: | Answer B is correct; you want to manage templates. Answer A is incorrect; you would use this option to create a new database. Answer C is incorrect; you would use this option to change configuration settings in a database that already exists. Answer D is incorrect; it is not an option in the DBCA.
A29: | Answer D is correct; you need to create a new tablespace that has the desired settings and then move the existing tables into that tablespace. Answer A is incorrect; you can meet the requirements easily without having to rebuild the database. Answer B is incorrect; you don't in any case need to touch the control files. Answer C is incorrect; you cannot simply alter the current tablespace to meet the cited requirements.
A30: | Answers A and D are correct. All newly started transactions will use the UNDOTBS_2 tablespace, and the UNDOTBS_1 enters into PENDING OFFLINE status as long as any active transactions are using it. Answer B is incorrect; currently active transactions will not switch but will continue using the UNDO tablespace to which they were originally assigned. Answer C is incorrect; it is permissible to switch to a new UNDO tablespace with active transactions in the database. Answer E is incorrect; new transactions will see UNDOTBS_2 as the active UNDO tablespace. Answer F is incorrect; you can have two UNDO tablespaces defined just not active at the same time.
A31: | Answer B is correct; extents are logical collections of database blocks. Answer A is incorrect; segments are made up of extents, not extents made up of segments. Answer C is incorrect; tablespaces are made up of segments and extents. Answer D is incorrect; operating system blocks are not necessarily contiguous.
A32: | Answer B is correct; IDENTIFIED GLOBALLY indicates that the user must be authorized to use the role by the enterprise directory service before it can be enabled. Answer A is incorrect; ar_clerk does not need to be authorized. Answer C is incorrect; it is identified by password. Answer D is incorrect; the role is authorized using a package. Answer E is incorrect; the role is authorized by the OS.
A33: | Answer B is correct; because the column has low cardinality and is rarely updated, a bitmap index would be best. Answer A is incorrect; although a B-tree index would work, it is not the optimum solution. Answer C is incorrect; simply sorting in the other order. Answer D is incorrect; there is no point in a function-based index.
A34: | Answer A is correct; low cardinality columns are prime candidates for bitmap indexes. Answer B is incorrect; there is no indication that the column is itself or that it is included in a set of unique columns. Answer C is incorrect; there is no indication that the table or the index should be partitioned. Answer D is incorrect; reverse key is not indicated. Answer E is incorrect; although the bitmap may be on a single column, that is not a type of index. Answer F is incorrect; there is no function indicated as associated with the column in question.
A35: | Answer B is correct. The SGA, as part of the memory structure, is created when the instance is started and remains allocated until the instance is shut down. Answer A is incorrect because the SGA isn't part of the database. Answer C is incorrect because user processes have to interact with an open instance, and the SGA, as a memory structure, opens when the instance opens. Answer D is incorrect because, as a memory structure, the SGA has to be available before any server processes can start.
A36: | Answer A is correct. When you use STARTUP NOMOUNT, the instance is started, and the database is not mounted. Answer B is incorrect because NOMOUNT means that the database has not been mounted. Answer C is incorrect because the database is neither mounted nor opened. Answer D is incorrect because the instance is started, and the database is not mounted.
A37: | Answer D is correct; regardless of the space management, rollback information is controlled in the undo tablespace. Answer A is incorrect; free space is managed in the extent. Answer B is incorrect; the control file plays no part in either space management or rollback information. Answer C is incorrect; in dictionary managed tablespaces, the data dictionary controls space management.
A38: | Answers A and D are correct; the directories in question already have to exist, and they must have the appropriate permissions to allow Oracle to write to them. Answer B is incorrect; it doesn't matter whether files already exist in the directory. Answer C is incorrect; the location of the directory is irrelevant.
A39: | Answer C is correct; with it you can alter the user lonny to be authenticated externally and have profile CLERK with this script. Answer A is incorrect; although it is authenticated externally, it grants a role not a profile to user lonny. Answer B is incorrect; it is authenticated with a password. Answer D is incorrect; it grants a role to lonny, not a profile.
A40: | Answers B and D are correct; Oracle creates an index for primary keys and for unique indexes. Answer A is incorrect; check constraints do not automatically have associated indexes. Answer C is incorrect; not null is not associated automatically with an index. Answer E is incorrect; foreign keys are not automatically associated with indexes.
A41: | Answer B is correct; to keep users from using the SYSTEM tablespace as a sort area, you should create a default temporary tablespace. Answer A is incorrect; an UNDO tablespace does not keep users from sorting in the SYSTEM tablespace. Answer C is incorrect; UNDO keyword creates an UNDO tablespace. Answer D is incorrect; although the TEMPORARY keyword creates a temporary tablespace, it is not a default temporary tablespace and therefore does not keep users not deliberately assigned to this tablespace from using the SYSTEM tablespace as a sort area.
A42: | Answer C is correct; the parse information and the bind variable information would be stored in the PGA and the library cache. Answer A is incorrect; it requires both the library cache with the PGA. Answer B is incorrect; the row cache won't participate in either the parse values or the bind variable information. Answer D is incorrect; it requires the PGA along with the library cache portion of the SGA. Answer E is incorrect; the buffer cache will not participate as it holds the data.
A43: | Answer C is correct; database writer performs the writing of the modified blocks to be written out to the data files. Answer A is incorrect. Log writer does not write data; it writes redo log files. Answer B is incorrect; the SYSTEM MONITOR does not write out any files. Answer D is incorrect; although checkpoint does participate in the checkpointing process, it does not write out the data to the data files. Answer E is incorrect; PROCESS MONITOR does not participate in the checkpoint or data writing process.
A44: | Answers D and G are correct; in the event of a network error that terminates a user's session, PMON will rollback the current transaction and release all table and row locks held by that session. Answer A is incorrect; checkpoints will not occur. Answer B is incorrect; no commits will happen automatically. Answer C is incorrect; recovery manager will not recover the session. Answers E and F are incorrect; SMON is not involved in cleaning up user sessions when they fail.
A45: | Answers C and D are correct; NEXT_EXTENT and PCT_INCREASE give you the information on the next extents. Answer A is incorrect; BLOCKS tells you the number of blocks in the segment but not the size of the next extent. Answer B is incorrect; nothing about free space will let you know about extent sizing. Answer E is incorrect; INITIAL_EXTENT plays only a minimal role in the next extent.
A46: | Answer B is correct; the SGA is created when the instance is started. Answer A is incorrect; the SGA needs to be available before the database is created to create the structures in the new database. Answer C is incorrect; the SGA needs to be available to mount the database. Answer D is incorrect; open comes after mounted, and therefore the SGA would have to be available. Answer E is incorrect; there is no SGA server process.
A47: | Answer C is correct; partitioning makes highly scalable applications and is useful to segment large tables so that they can be accessed in parallel. Answer A is incorrect; a regular table is far less scalable than a partitioned table. Answer B is incorrect; cluster tables often speed up access but not in parallel. Answer D is incorrect; index organized tables are not any more parallelizable than the others.
A48: | Answer A is correct; 1/1440 is 1 minute. Answer B is incorrect; 5 minutes plays no part in any of the equation. Answer C is incorrect; grace time is 10 minutes, not the lock out time. Answer D is incorrect; 14 minutes is not one of the options. Answer E is incorrect; 18 minutes is not one of the options. Answer F is incorrect; 60 days is the life of the password, not the number of minutes that the password is locked.
A49: | Answer C is correct; the order that Oracle searches for the initialization files is spfile<sid>.ora, spfile.ora, init<sid>.ora, and finally, init.ora. Answer A is incorrect; init.ora would be the last file to be searched for. Answer B is incorrect; spfile<sid>.ora would be before spfile.ora. Answer D is incorrect; the init.ora files would be searched after the spfile.ora files.
A50: | Answer A is correct; ENABLE NOVALIDATE would provide the required validation. Answer B would disable the constraint. Answer C is incorrect; ENABLE VALIDATE would enable the constraint but validate the current data. Answer D is incorrect; it would disable the constraint.
A51: | Answers A, C, and E are correct; data blocks are logical structures. Segments consist of at least one extent when they are created. A tablespace can consist of several data files each on the same or different disks. Answer B is incorrect; multiple files can belong to a tablespace but not vice versa and would create error conditions. Answer D is incorrect; data blocks of an extent have to belong to the same file. Answer F is incorrect; because you can have multiple files to a tablespace, you can have extents from more than one file.
A52: | Answer B is correct; you would need to set the LOG_CHECKPOINT_TIMEOUT value, force a checkpoint with the FAST_START_MTTR_TARGET, and then go start monitoring the alert log files to watch checkpoints. Answer A would not provide sufficient information in the alert logs but would provide information only from that period forward. To be sure of the information that you gather, you need to have a beginning and an end point, created with a forced checkpoint. Answer C would provide more than enough information in the log switch but not sufficient with the checkpointing. Answer D is incorrect; you don't force the checkpoint with the ALTER SYSTEM CHECKPOINT command to gather the required information.
A53: | Answers A, C, and E are correct; each file is a member, all the members belong to a group, and the sequence number of the currently active redo log group is stored in the control file. Answer B is incorrect; the members in a group are identical. Answer D is incorrect; Oracle needs at least two groups to function. Answer F is incorrect; archived redo log files are not written to at the same time as the online redo log files.
A54: | Answer B is correct; in order they are tablespaces, segments, extents, and Oracle blocks. Answer A is incorrect; data files are typically bigger than extents. Answer C is incorrect; databases are bigger than tablespaces. Answer D is incorrect; databases are bigger than tablespaces. Answer E is incorrect. Data files are not logical; they are physical.
A55: | Answers B, C, and E are correct; the extents are released, the definition is removed from the data dictionary, and if there are PK FK relationships, CASCADE CONSTRAINTS needs to be specified. Answer A is incorrect; there do not need to be underlying tables for synonyms. Answer D is incorrect; triggers and indexes are dropped as well.
A56: | Answer D is correct; rolling back transactions is an example of transaction rollback. Answer A is incorrect; there is no such thing as insert recovery. Answer B is incorrect; read consistency is accomplished with rollback information but not when a statement fails. Answer C is incorrect; roll forward is transaction recovery.
A57: | Answer C is correct; the user did not provide the password leighlynn to connect as SYSDBA. Answer A is incorrect; angela needed SYSDBA not dba. Answer B is incorrect; SYSDBA is required not SYSOPER. Answer D is incorrect; angela is stored in the password file.
A58: | Answer B is correct; parameters on the server provide defaults, parameters on the client override locale-dependent variables, and alter session parameters override whatever they specify.
A59: | Answers B and D are correct. Oracle looks in the SPFILE and the INIT file for its initialization parameters. Answer A is a control file and provides useful information to the database and instance, but does not contain initialization parameters. Answer C is a data file, not a parameter file.
A60: | Answer D is correct. Columns that appear commonly in a where clause should be indexed. Answer A is incorrect; care should be taken to not index all columns updated frequently. Answer B is incorrect; often indexes are necessary even on regularly updated columns. Answer C is incorrect; all columns are queried at some point or they would be irrelevant in the database. Answer E is incorrect; data warehouses are typically highly indexed.


Chapter 21. Practice Exam 2

1:

You are the new DBA onsite, and you need to find the name and location of your control files. Which of the following is not a location in which you can find that information?

  • A. V$PARAMETER

  • B. V$CONTROLFILE

  • C. V$CONTROLFILE_RECORD_SECTION

  • D. spfil<sid>.ora file

2:

User Michael has INSERT privileges on the GL_RECORDS table. What will Michael notice first when you revoke this privilege?

  • A. All the records inserted by the user will be removed from the database.

  • B. The user will be removed from the database.

  • C. The user will no longer be able to create tables.

  • D. The user will not be able insert any more information into the GL_RECORDS table.

3:

The location and size of all the indexes in your database can be found in which data dictionary view?

  • A. USER_INDEXES

  • B. USER_SEGMENTS

  • C. DBA_INDEXES

  • D. DBA_OBJECTS

  • E. None of the above

4:

What single profile areas can be used to control resource usage of the others?

  • A. connect_time

  • B. logical_reads_per_session

  • C. private_sga

  • D. cpu_per_session

  • E. composite_limit

5:

You are assigning a default role for users. Which of the following is not an acceptable method for assigning a default role?

  • A. ALTER USER DEFAULT ROLE NONE EXCEPT mydefaultrole;

  • B. ALTER USER DEFAULT ROLE ALL;

  • C. ALTER USER DEFAULT ROLE NONE;

  • D. ALTER USER DEFAULT ROLE ALL EXCEPT ALL EXCEPT mydefaultrole;

6:

You have a database with automatic archiving of redo logs enabled. All your redo log files are on the same physical disk. Where might you find conflicts occurring with background process?

  • A. PMON and SMON

  • B. DBWR and LGWR

  • C. ARCH and LGWR

  • D. LGWR and PMON

7:

In which of the following tablespaces would you find the data dictionary information?

  • A. SYS tablespace

  • B. SYSTEM tablespace

  • C. Dictionary tablespace

  • D. UNDO tablespace

8:

You are the new DBA, and you need to reorganize one of your tablespaces. What privilege will you need to log on to the database when the database is up and open but not available to users?

  • A. CREATE SESSION

  • B. CONNECT

  • C. RESOURCE

  • D. RESTRICTED SESSION

9:

You need to do maintenance on a table in a dictionary managed tablespace. You need to alter the initial segment size for a given table. Which of the following keywords would have to be used to accomplish this feat?

  • A. ALTER TABLE

  • B. RESIZE

  • C. DROP TABLE

  • D. COALESCE

10:

Examine the following statement:

CREATE TABLE friends
(friend_id NUMBER (5),
Flast_name VARCHAR2(45),
Ffirst_name VARCHAR2 (45),
Street_addr1 VARCHAR2(60),
Street_addr2 VARCHAR2 (60),
Fcity VARCHAR2 (45),
Vstate CHAR(2),
Vzip VARCHAR215)
CONSTRAINT pk_friend primary_key (friend_id))
TABLESPACE mydata1
EXTENT MANAGEMENT LOCAL;

What is wrong with this statement?

  • A. There are too many columns.

  • B. The primary key is declared incorrectly.

  • C. The storage clause is wrong.

  • D. You have to declare an index tablespace for the primary key index.

11:

Which is not an appropriate storage parameter for indexes?

  • A. TABLESPACE

  • B. OPTIMAL

  • C. INITIAL

  • D. PCTINCREASE

12:

You are working on determining how Oracle processes user statements. SQL and PL/SQL statements' parse information is stored in which of the following memory areas?

  • A. Row cache

  • B. Buffer cache

  • C. Library cache

  • D. Dictionary cache

13:

Information from the buffer cache is saved back to disk in all the following situations except one. In which situation does this not occur?

  • A. At log switch

  • B. When a timeout occurs

  • C. When the shared pool is flushed

  • D. When a checkpoint occurs

14:

You have just created your first new database. Which two scripts do you need to run to create your data dictionary structures and the Oracle supplied packages?

  • A. catalog.sql

  • B. utlrp.sql

  • C. catproc.sql

  • D. utlpwdmg.sql

15:

You created a new user in your database. You instruct the user with the ID and password necessary to log on, but he still complains that he is getting errors stating that there are insufficient privileges. Which of the following would you do?

  • A. GRANT CREATE TABLE to the user.

  • B. Unlock the user's account.

  • C. Reset the user's password.

  • D. GRANT CONNECT to the user.

16:

You enabled auditing in the database with the following statement:

AUDIT UPDATE, DELETE
ON GL.GL_RECORDS
BY ACCESS
WHEN NOT SUCCESSFUL;

Which describes how Oracle will now audit data?

  • A. All successful inserts on the table will be recorded.

  • B. All unsuccessful inserts on the table will be recorded.

  • C. All successful updates and deletes will be recorded.

  • D. All unsuccessful updates and deletes will be recorded.

17:

You issue the following statement:

DROP PROFILE developer_profile;

This profile was granted to several users in the active database. What will happen to these users?

  • A. All users who had the profile will no longer be able to log on to the database.

  • B. All users who had the profile no longer have any profile.

  • C. All users who had the profile now have the DEFAULT profile.

  • D. You cannot drop the profile as long as there are users to whom it is assigned.

18:

You need to restart your database. At 4:30 p.m., you issue the SHUTDOWN command. After two hours, the database is still in the process of shutting down. Which of the following commands did you most likely issue to initiate the shutdown?

  • A. SHUTDOWN IMMEDIATE;

  • B. SHUTDOWN ABORT;

  • C. SHUTDOWN TRANSACTIONAL

  • D. SHUTDOWN NORMAL

19:

You need to see the initialization parameter settings for your Oracle 9i database. Which of the following choices is not a method used to obtain this information?

  • A. Check the spfile.ora.

  • B. Use OEM Instance Manager.

  • C. Issue SELECT * FROM V$PARAMETER; in SQL*Plus.

  • D. Issue SELECT * FROM DBA_PARAMETERS; in SQL*Plus.

20:

You have been instructed to set up auditing on the invoice entry system. The requirement is that whenever the invoice status changes to paid, an entry is entered into the payment table. Which of the following represents the best way to perform this auditing?

  • A. Statement auditing

  • B. Object auditing

  • C. Access auditing

  • D. Value-based auditing

21:

When a user issues a COMMIT statement in his session, which of the following will not occur? [check all that apply]

  • A. Acquired lock on the table or row is released.

  • B. Redo entry generated for committed transaction.

  • C. Cached data saved immediately to disk.

  • D. All users can see alterations made to the data.

22:

Which of the following is not a valid segment type in Oracle 9i?

  • A. Sequence segment

  • B. Data segment

  • C. Temporary segment

  • D. Undo segment

23:

Where would you find the amount of free space available in a tablespace?

  • A. DBA_TABLESPACE

  • B. DBA_FREE_SPACE

  • C. V$FREE_SPACE

  • D. V$TABLESPACE

24:

Which of the following describes what happens after the listener process detects a user trying to connect to the database with dedicated servers being used?

  • A. The listener will spawn a new server process.

  • B. The listener will pass the request to a dispatcher.

  • C. The listener will pass the request to the LGWR process.

  • D. The listener will pass the request to the DBW n process.

25:

Which of the following choices correctly identifies exactly when Oracle reads the init.ora file?

  • A. When the instance is started

  • B. When the database is started

  • C. When the database is opened

  • D. When the database is shut down

26:

You have decided to use Oracle Managed File Systems. You have issued a CREATE TABLESPACE command. Which of the following parameters tell you where Oracle placed the data file that it associated with the new tablespace?

  • A. DB_FILE_DEST

  • B. DB_CREATE_FILE_DEST

  • C. DB_CREATE_ONLINE_LOG_1

  • D. The directory is operating system dependent.

27:

You have determined that you need to shut down your database quickly. Which of the following commands would you use to accomplish this if you were prepared to allow Oracle to perform instance recovery when you started back up?

  • A. SHUTDOWN IMMEDIATE

  • B. SHUTDOWN TRANSACTIONAL

  • C. SHUTDOWN NORMAL

  • D. SHUTDOWN ABORT

28:

If you want to use Oracle Managed File Systems to handle the locations of redo logs, minimally, what is the number of destinations you need to specify for the associated parameter in the init.ora file?

  • A. 3

  • B. 1

  • C. 2

  • D. 0

29:

You are preparing to manually create an Oracle 9i database. Which of the following parameters must be changed in the new copy of your init<SID>.ora file to create a database that will not interfere with any existing databases on the host machine?

  • A. DB_BLOCK_SIZE

  • B. CONTROL_FILES

  • C. SHARED_POOL_SIZE

  • D. MAX_DATAFILES

30:

You are using DBCA to configure a database. Which of the following terms refers to the DBCA object on which you can base your configuration settings?

  • A. Template

  • B. Clone

  • C. Copy

  • D. CP

31:

When configuring new profiles in your database, which of the following is not an area on which you can specify a resource profile?

  • A. LOGICAL_READS_PER_SESSION

  • B. CONNECT_TIME

  • C. IDLE_TIME

  • D. LOGICAL_WRITES_PER_SESSION

32:

Which of the following alterable characteristics can a user change by herself?

  • A. DEFAULT TABLESPACE

  • B. IDENTIFIED BY

  • C. TEMPORARY TABLESPACE

  • D. QUOTA

33:

To attach an additional role to a user, which command is most appropriate?

  • A. ALTER USER

  • B. ALTER SYSTEM

  • C. ALTER ROLE

  • D. GRANT

34:

Which of the following requires the use of undo segments? [check all that apply]

  • A. INSERT

  • B. UPDATE

  • C. DELETE

  • D. SELECT

35:

You are attempting to clear an unarchived redo log file. To do this, you are attempting to manually cause a log switch. Which of the following statements will accomplish this?

  • A. ALTER DATABASE

  • B. ALTER SYSTEM

  • C. ALTER SESSION

  • D. You cannot manually switch log files.

36:

Which of the following statements is available for the ALTER USER but not for the CREATE USER statement.

  • A. IDENTIFIED BY

  • B. TEMPORARY TABLESPACE

  • C. DEFAULT ROLE

  • D. PROFILE

37:

You have already defined your national character set in your database to be English. Some of the fields in our tables contain German characters. To ensure that you can sort the fields containing these characters correctly, the following parameters should be set:

  • A. NLS_DATE_FORMAT

  • B. NLS_SORT_ORDER

  • C. NLS_TERRITORY

  • D. NLS_SORT

38:

You are maintaining a database in multiple countries in multiple languages. To help you to determine what the date conventions are for the database in any given country, you might be able to query which of the following data dictionary views?

  • A. V$NLS_DATE

  • B. DBA_DATE_FORMAT

  • C. NLS_DATE_FORMAT

  • D. V$NLS_PARAMETERS

39:

You need to remove a column from a table in your database, and the column has considerable data in it. Which of the following best provides a means by which you can accomplish this if your primary objective is to remove the column quickly and not necessarily free up any of the used space?

  • A. ALTER TABLE DROP COLUMN

  • B. ALTER TABLE MODIFY COLUMN

  • C. ALTER TABLE RENAME COLUMN

  • D. ALTER TABLE SET UNUSED COLUMN

40:

You are using locally managed tablespaces; how does Oracle implement this?

  • A. Using a bitmap in the space header segment

  • B. Using the data dictionary locally

  • C. Using an independent flat file in the file system

  • D. Using special information in the data dictionary that only that table can get to

41:

You issued the following statement on a database where the standard block size is 4K.

CREATE TABLESPACE myindexes
DATAFILEDatafile '/oracle/data/indexes01.dbf'
SIZE 100M
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 50k
ONLINE;

How many blocks will each bit represent in the bitmap area of the locally managed data files?

  • A. 13

  • B. 50

  • C. 100

  • D. 4

42:

Which pair of words completes the following statement?

When the STARTUP NOMOUNT command is issued, the Oracle instance is _____________, and the Oracle database is ______________?

  • A. Started, not mounted

  • B. Started, mounted

  • C. Started, opened

  • D. Not started, not mounted

43:

You are creating a new control file to replace ones that have been deleted. Which of the following commands is the appropriate way to start the database?

  • A. STARTUP NOMOUNT

  • B. STARTUP READ-ONLY

  • C. STARTUP OPEN

  • D. STARTUP

44:

What two tools can be used for starting up and shutting down the Oracle instance and database? [select two]

  • A. SQL*Plus

  • B. Server Manager

  • C. Enterprise Manager

  • D. PL/SQL

45:

Which three views would provide you with information about tables in the database?

  • A. DBA_TABLES

  • B. DBA_TABLESPACES

  • C. V$TABLES

  • D. USER_TABLES

  • E. ALL_TABLES

46:

Which of the following would be a dynamic performance view in the data dictionary?

  • A. V$SESSION

  • B. DBA_PERFORMANCE

  • C. DBA_DATA_FILES

  • D. DBA_EXTENTS

47:

Who owns the data dictionary?

  • A. Oracle

  • B. SYS

  • C. The DBA

  • D. SYSTEM

48:

At what point does the CKPT process write data blocks to the data files? [select all that apply]

  • A. Whenever LOG_CHECKPOINT_INTERVAL parameter tells it to.

  • B. Whenever LOG_CHECKPOINT_TIMEOUT tells it to.

  • C. Whenever there is a log switch.

  • D. CKPT doesn't write anything out to files; it tells the other processes to do that.

49:

User crystal has had the following ALTER USER statement run against her userid:

ALTER USER crystal
QUOTA MYDATA 0K
QUOTA MYDATA2 100M;

As soon as the command has finished, crystal attempts to add data to her address table that already existed in MYDATA and was at an extent barrier. What is the effect of the insert?

  • A. Because the table already existed, the insert was successful.

  • B. The table was automatically moved when the ALTER USER command was run, so the insert was successful.

  • C. The table still exists in the MYDATA tablespace but cannot be added to because the quota is now 0.

  • D. The table has been dropped as a side effect of the ALTER USER command, so the insert was unsuccessful.

50:

Which statement is true about segments?

  • A. Each table has its own segment.

  • B. A segment is created every time an extent is created, extended, or altered.

  • C. An index segment is created every time a table is created.

  • D. A segment is deleted whenever a table is truncated.

51:

When is the SGA created in an Oracle instance?

  • A. When the database is created

  • B. When the instance is opened

  • C. When the user process is started

  • D. When a server process is started

52:

You have been monitoring the usage of an index that you believe to be underused on a table. You find that the index is used extensively but only during the first week of the month, when Accounting is running month-end processing. The rest of the month, the index is used only rarely despite the fact that it is an actively updated table. What could you do to speed up processing during the majority of the month, yet allow queries to run as rapidly as possible during the month-end processing?

  • A. Drop the index; it is obviously only used 25% of the time.

  • B. Move the index to another tablespace.

  • C. Drop the index after the month-end processing and rebuild it right before the next month-end processing.

  • D. Rebuild the index immediately before the month-end processing.

53:

Which statements are true in relation to the number of indexes on a table? [select all that apply]

  • A. Every column ID in a table that is subject to update will see update performance improve with the addition of at least one index on the column.

  • B. Every column that participates in a query should have an index.

  • C. There is a limit of 32 indexes on a table.

  • D. There is a limit of 32 columns in an index.

  • E. Columns that are often queried as part of a where clause are good candidates for an index.

54:

After running ANALYZE INDEX claim_id_idx VALIDATE STRUCTURE, you query the INDEX_STATS view and learn that you have a rather high ratio of deleted leaf rows (DEL_LF_ROWS) to leaf rows (LF_ROWS). In fact, the ratio ends up being almost 40%. You decide that you need to reorganize the index to free up some of the extra space but that the space should remain allocated to the index so that it can be reused for new entries. Which command or commands would allow you to perform this task while maintaining the minimum impact on the users who are running queries on the system? [select all that apply]

  • A. DROP INDEX followed by CREATE INDEX

  • B. ALTER INDEX REBUILD

  • C. ALTER INDEX COALESCE

  • D. ALTER INDEX DEALLOCATE UNUSED

55:

To determine which roles are available in the database, use the __________ view, and to determine which system privileges have been granted to a role, use the ___________ view.

  • A. DBA_ROLES, DBA_SYS_PRIVS

  • B. DBA_ROLES, DBA_SYSTEM_PRIVS

  • C. SESSION_ROLES, DBA_SYS_PRIVS

  • D. DBA_ROLES, DBA_TAB_PRIVS

56:

Which predefined role is useful for database administrators because it requires having all the administrative privileges needed to maintain the entire database?

  • A. DBA

  • B. SYSTEM

  • C. SYSOPER

  • D. RESOURCE

57:

You create a role called developer and grant CREATE TABLE and SELECT ANY TABLE to that role. Then you grant the role to user Lynn. Lynn then logs in to the database. What is true about Lynn's ability to manipulate tables in the database?

  • A. She can create and select from tables immediately after she logs in.

  • B. She can create and select from tables after she logs out and back in.

  • C. She has to have DEVELOPER deliberately set as her default role before she can manipulate tables.

  • D. She has to have CREATE TABLE and SELECT ANY TABLE granted to her directly before she can manipulate tables.

58:

Which privilege enables a user to create a foreign key relationship on another user's table?

  • A. CREATE INDEX

  • B. CREATE ANY INDEX

  • C. REFERENCES

  • D. CREATE ANY KEY

59:

Which of the following statements is true to enable auditing in the database?

  • A. To set up auditing in Oracle, the AUDIT_TRAIL initialization parameter must be set to DB or OS.

  • B. To set up auditing in Oracle, the BEGIN_AUDIT initialization parameter must be set to trUE.

  • C. To set up auditing in Oracle, the AUDIT_TRAIL initialization parameter must be set to NONE.

  • D. To set up auditing in Oracle, the AUDITING initialization parameter must be set to TRUE.

60:

Your company has decided to implement a password expiration plan. What parameter do you need to set to cause all passwords to expire every 60 days?

  • A. PASSWORD_LIFE_TIME

  • B. PASSWORD_EXPIRATION_DAYS

  • C. PASSWORD_REUSE_TIME

  • D. PASSWORD_GRACE_TIME


Chapter 22. Exam 2 Answers

1. C

2. D

3. E

4. E

5. A

6. C

7. B

8. D

9. C

10. B

11. B

12. C

13. C

14. A, C

15. D

16. D

17. C

18. D

19. D

20. D

21. C

22. A

23. B

24. A

25. A

26. B

27. D

28. C

29. B

30. A

31. D

32. B

33. D

34. A, B, C

35. B

36. C

37. D

38. D

39. D

40. A

41. A

42. A

43. A

44. A, C

45. A, D, E

46. A

47. B

48. D

49. C

50. A

51. B

52. C

53. D, E

54. C

55. A

56. A

57. A

58. C

59. A

60. A

A1: | Answer C is correct; the only one of the provided places that will not give you information on your control file locations and names is V$CONTROLFILE_RECORD_SECTION. Views V$CONTROLFILE and V$PARAMETER will both provide the needed information, as will the initialization parameter files.
A2: | Answer D is correct; the user will no longer be able to insert records into the table from which he had his insert privileges revoked. Answer A is incorrect; revoking privileges will have no effect on records already inserted into the database. Answer B is incorrect; revoking privileges will not remove the user from the database. Answer C is incorrect; the user will still be able to create tables in his own schema if he was able to do that before.
A3: | Answer E is correct; none of these answers alone will provide the information required. Answer C is incorrect; you can find information on all the indexes in the database in the DBA_INDEXES view but not all the information required. Answer A is incorrect; USER_INDEXES provides only information on the indexes owned by the logged-in user. Answer B is incorrect; USER_SEGMENTS will similarly provide only information pertinent to the logged-in user.
A4: | Answer E is correct; each of the other selections can be rolled up into composite_limit. This question needs to be read very carefully, and a basic understanding of what each of the parameters does is needed.
A5: | Answer A is correct; all the options are correct, except DEFAULT ROLE NONE EXCEPT <rolename>. EXCEPT is only acceptable with the ALL keyword, not the NONE keyword.
A6: | Answer C is correct; you may find that you have conflicts on disk resources if LGWR and ARCH both try to access the same disk resources at the same time. This can occur when one log is being archived at the same time as LGWR. Answer A is incorrect; first because SMON and PMON won't conflict, and second because they have nothing to do with the question. Answer B is incorrect because you can't infer that the data files will also be on the same physical disk. Answer D is incorrect because PMON won't conflict with LGWR.
A7: | Answer B is correct; the data dictionary is in the system tablespace. Answer A is incorrect; there is no SYS tablespace when you create the database. SYSTEM tablespace is the first to be created. Answer C is incorrect; again there is no dictionary tablespace created in a database by default. Answer D is incorrect; undo information is stored in the undo tablespace not data dictionary information.
A8: | Answer D is correct; you need to have been granted RESTRICTED SESSION to connect to the database under the given circumstances. Answers A, B, and C are all incorrect for the same reasons. They will only allow you to connect when the database is open normally.
A9: | Answer C is correct. To alter the initial extent of a table, you have to drop and re-create the table. Answer A is incorrect; you can alter the next extent but not the initial extent. Answer B is incorrect; you cannot resize the initial extent of a table. Answer D is incorrect; you coalesce free space, but that does not alter extents in any way.
A10: | Answer B is correct; the primary key declaration should not have an underscore between primary and key. Answer A is incorrect; there can be 1,000 columns in an Oracle 9i table. Answer C is incorrect; LOCALLY MANAGED is declared in this fashion. Answer D is incorrect; the index for this constraint will go into the user's default tablespace, even if that is still SYSTEM.
A11: | Answer B is correct; OPTIMAL is a setting for undo in manual undo management, not for indexes. The others are all applicable storage settings.
A12: | Answer C is correct; the parse information is stored in the library cache. This area is also often referred to as the shared SQL area for this reason. Answer A is incorrect; retrieved row information is stored in the row cache. Answer B is incorrect; it is where blocks are stored for quicker retrieval. Answer D is incorrect; it is where data dictionary information is stored for quick retrieval.
A13: | Answer C is the only correct answer. The only one of the given situations that will not result in data from the buffer cache being written to disk is when you flush the shared pool.
A14: | Answers A and C are correct; you need to run catalog.sql and catproc.sql to build these structures. Answer B is incorrect; utlrp.sql recompiles invalid objects. Answer D is incorrect; utlpwdgm.sql provides password management facilities.
A15: | Answer D is correct; you need to grant the CONNECT role to the user. Answer A is incorrect, CREATE TABLE will not help them to connect. Answers B and C are incorrect; the error does not suggest that either of these is needed.
A16: | Answer D is correct; unsuccessful deletes and updates will be recorded. The statement says updates and deletes, so answers A and B are incorrect. Answer C is incorrect because you are auditing unsuccessful inserts instead of successful inserts.
A17: | Answer C is correct; the users to whom this profile was granted will now have as their profile the DEFAULT profile. Answer A is incorrect; dropping a profile will not affect their ability to log on. Answer B is incorrect; every user has a profile. Unless one is explicitly given, it is the DEFAULT profile. Answer D is incorrect; you can drop a profile any time.
A18: | Answer D is correct; you probably issued the SHUTDOWN NORMAL command, which means that the database will shut down when all user processes have been disconnected. Answer A is incorrect; SHUTDOWN IMMEDIATE will log off the users and shut down elegantly. Answer B is incorrect; SHUTDOWN ABORT will shut down immediately. Answer C is incorrect; SHUTDOWN TRANSACTIONAL will allow the users to finish the current transactions and will then log them off and shut down.
A19: | Answer D is correct; the only choice that will not allow you to determine initialization parameters is selecting from DBA_PARAMETERS, which is not a valid data dictionary view.
A20: | Answer D is correct; value-based auditing will meet these requirements. Answer A is incorrect; statement auditing wouldn't provide you the desired results. Answer B is incorrect; object auditing would not provide the desired results. Answer C is incorrect; access auditing wouldn't give you the granularity required.
A21: | Answer C is correct; cached data will not necessarily be written immediately out to disk. The other answers will all occur.
A22: | Answer A is correct; the only nonvalid segment type is sequence segment.
A23: | Answer B is correct; you can best find out the available free space by querying DBA_FEE_SPACE. Answer A is incorrect; it will provide you with allocated information but not free space information. Answer C is incorrect; V$FREE_SPACE is not a valid view. Answer D is incorrect, V$TABLESPACE will tell you only what the tablespace name and number are.
A24: | Answer A is correct; the listener will spawn a new user process. Answer B is incorrect because you are running in dedicated server mode. Answers C and D are incorrect because the listener does not interact directly with either LGWR or DBWn.
A25: | Answer A is correct; the only time that the init.ora file is read is when the instance is started.
A26: | Answer B is correct; Oracle will place the data file in the location assigned to the DB_CREATE_FILE_DEST parameter. Answer A is incorrect; DB_FILE_DEST is not a valid parameter. Answer C is incorrect; DB_CREATE_ONLINE_LOG_n is where Oracle will place the redo log files and control files in OMF. Answer D is incorrect; the location is controlled by Oracle not the operating system.
A27: | Answer D is correct; if you are willing to allow Oracle to perform instance recovery when the database is reopened, you should use the SHUTDOWN ABORT command. Answer A is incorrect; SHUTDOWN IMMEDIATE is the quickest of the remaining alternatives, but will still not shut it down necessarily quickly. Answer B is incorrect; SHUTDOWN TRANSACTIONAL will allow currently running transactions to complete. Answer C is incorrect; SHUTDOWN NORMAL will politely wait for all users to log off and can take an extremely long time to complete.
A28: | Answer C is correct. By default, Oracle will try to multiplex redo log files and will need two locations specified to manage the logs.
A29: | Answer B is correct; you need to change the name, minimally, of the control files so that you don't overwrite existing files with ones for the new database. Answers A, C, and D are all incorrect because all these parameters can be the same in all databases on your system.
A30: | Answer A is correct; you base future decisions, often, on templates. Answer B is incorrect; a clone is a duplicate of an existing database. Answers C and D are incorrect; they are operating system commands used to make copies of existing files.
A31: | Answer D is correct; LOGICAL_WRITES_PER_SESSION does not exist. LOGICAL_READS_PER_SESSION, however, does exist.
A32: | Answer B is correct; the only alterable characteristic listed that the user can alter herself is her password via the IDENTIFIED BY keyword.
A33: | Answer D is correct; you grant a role to a user. Answer A is incorrect; you don't need to alter the user to attach a new role to a user. Answer B is incorrect; ALTER SYSTEM will do nothing for an individual user. Answer C is incorrect; ALTER ROLE will change the role's characteristics but not to whom it is attached.
A34: | Answers A, B, and C are all correct; answers, inserts, updates, and deletes all require undo segments.
A35: | Answer B is correct; to switch log files, you have to use the ALTER SYSTEM command. Answer A is incorrect; you don't use ALTER DATABASE to switch log files. Answer C is incorrect; log files are not controlled at the session level. Answer D is incorrect because Answer B is correct.
A36: | Answer C is correct; the default role parameter is available in the ALTER USER statement but not in the CREATE USER statement. Answer A is incorrect; to create a user, you have to provide an authentication mechanism. Answer B is incorrect; you can give a user a temporary tablespace at creation or alteration time. Answer D is incorrect; PROFILE is available at either juncture.
A37: | Answer D is correct; setting NLS_SORT in your session will allow you to override the sort order and specify a language other than the national language set specified for the database. Answer A is incorrect; NLS_DATE_FORMAT identifies a date format, not any character characteristics. Answer B is incorrect; NLS_SORT_ORDER isn't a valid parameter. Answer C is incorrect; NLS_TERRITORY helps to identify peculiarities of the geographical locations where the database may be running.
A38: | Answer D is correct; V$NLS_PARAMETER will tell you the information you need. Answers A and B are not valid database views. Answer C is an initialization parameter, not a view.
A39: | Answer D is correct; you would set the column unused so that it disappears from the table, but none of the data has actually been removed. You can reclaim the space later if necessary. Answer A is incorrect; if you drop the column, it won't necessarily be quick. Answer B is incorrect; modifying it won't get rid of it. Answer C is incorrect; renaming it won't get rid of it.
A40: | Answer A is correct, locally managed tablespaces are managed in the space header segment of the tablespace. Answers B and D are incorrect and should be discarded immediately because of the data dictionary references. Answer C is incorrect; Oracle does not store this information in flat file format.
A41: | Answer A is correct. Because they are 4K blocks and each extent is 50K, each bit will represent 50/4 or 12.5 or, rounded, 13.
A42: | Answer A is correct. When you use STARTUP NOMOUNT, the instance is started; the database is not mounted. Answer B is incorrect because nomount means that the database has not been mounted. Answer C is incorrect because the database is neither mounted nor opened. Answer D is incorrect because the instance is started, and the database is not mounted.
A43: | Answer A is correct. STARTUP NOMOUNT will allow you to create a new control file without worrying about it attempting to access or open data files. Answer B is incorrect because the data files and control files have to be accessible and open for the queries in a read-only database to be processed. Answer C is incorrect because the control file has to be available to open the database. Answer D is simply a restatement of answer C and is therefore incorrect for the same reasons.
A44: | Answers A and C are correct; you can start up or shut down an instance either using SQL*Plus or through the Enterprise Manager interface. Answer B is incorrect; Server Manager is a desupported tool that used to be used for this purpose, but is no longer available as of Oracle 9i. Answer D is incorrect; the PL/SQL procedural language will not start up or shut down the database.
A45: | Answers A, D, and E are correct. Recall that for every DBA_ view, there is a corresponding ALL_ view and a USER_ view to provide different views on the same information depending on the information needed and the privileges granted. Answer B would provide information about tablespaces but not tables. Answer C, V$TABLE, might be inferred to be a dynamic performance view; however, it isn't a view in the database, and it would not provide information about tables but about their performance.
A46: | Answer A is correct. V$SESSION, and all the V$ views, are dynamic performance views. Answer B, DBA_PERFORMANCE, is not a table nor a view in the data dictionary. Answer C, DBA_DATA_FILES, provides information on data files in the database but is not dynamic. Answer D, DBA_EXTENTS, provides some information from which you can infer performance information, maybe, but is also not a dynamic view.
A47: | Answer B is correct. SYS owns the data dictionary. Answer A is incorrect because Oracle is not a privileged user of the database, only the server system that runs the instance. Answer C is incorrect because, although the DBA manages the database and the instance, and by extension the data dictionary, he or she does not own the data dictionary. Answer D is incorrect because the data dictionary is housed within the SYSTEM tablespace but is not owned by the user SYSTEM.
A48: | Answer D is the only correct answer. Checkpoint doesn't actually write anything out to files; it causes the DBW n process to write the data from the database buffer cache out to the database files. Answer A is incorrect because LOG_CHECKPOINT_INTERVAL tells CKPT how often in terms of volume to cause a checkpoint, but it does not ever write anything. Answer B is incorrect because LOG_CHECKPOINT_TIMEOUT tells CKPT how often in terms of periods of time in seconds to cause a checkpoint, but it does not ever write anything. Answer C is incorrect because a log switch causes CKPT to occur, but it does not ever write anything.
A49: | Answer C is correct; the table exists and can be selected from, but no inserts can occur because the quota is 0. Answer A is incorrect; the quota was reduced to 0; therefore, the insert failed. Answer B is incorrect; the ALTER USER statement will not move a table. Answer D is incorrect; the ALTER USER statement will not delete a table.
A50: | Answer A is correct. Each table, index, or other database object has its own segment. Answer B is incorrect because a segment is made up of multiple extents. Answer C is incorrect because index segments are created for indexes, and table segments are created for tables. Answer D is incorrect because the only time a segment is deleted is when the object that the segment is created on is dropped or truncated with either the REUSE STORAGE or DROP STORAGE parameters included.
A51: | Answer B is correct. The SGA, as part of the memory structure, is created when the instance is started and remains allocated until the instance is shut down. Answer A is incorrect because the SGA isn't part of the database. Answer C is incorrect because user processes have to interact with an open instance, and the SGA, as a memory structure, opens when the instance opens. Answer D is incorrect because, as a memory structure, the SGA has to be available before any server processes can start.
A52: | Answer C is correct; you can drop the index right after month-end processing is complete so that the inserts and updates won't have to update the indexes when they aren't being used and then rebuild the index right before the period when the index is heavily used. Answer A is incorrect; the index is heavily used for that one week of the month, and the index, at that point, is very advantageous. Answer B is incorrect; moving the index won't have any effect on the use of the index. Answer D is incorrect; rebuilding the index won't cause it to be used more or less, only to use space more efficiently.
A53: | Answers D and E are correct. Columns in a where clause are good candidates for indexes because they are limiting factors in queries, and there is a hard limit in Oracle that an index can only have 32 participating columns. Answer A is incorrect; indexes don't help insert, update, and delete performance. Answer B is incorrect; any column can participate in a query but not every column should have an index. Answer C is incorrect; there is no limit on the number of indexes on a table.
A54: | Answer C is correct; you will need to run the ALTER INDEX COALESCE command to avoid impacting users who are running queries that will need to access the index while the reorganization is in process. Answer A is incorrect; dropping the index and re-creating it would have detrimental effects on the users on the system. Answer B is incorrect; ALTER INDEX REBUILD would eliminate the gaps in the leaf blocks, but Oracle locks the base table whose index is about to be rebuilt, and no changes to the data in the base table can occur. Answer D is incorrect; it would have a detrimental effect on users and would not eliminate the holes in the leaf blocks.
A55: | Answer A is correct; DBA_ROLES is used for determining the available roles in the database, and the DBA_SYS_PRIVS view is used to determine which of them have system privileges. Answer B is incorrect; DBA_SYSTEM_PRIVS is not a view in the database. Answer C is incorrect; SESSION_ROLES tells you only the roles assigned to the currently logged-in user. Answer D is incorrect; DBA_TAB_PRIVS tells you the object privileges assigned to roles, not system privileges.
A56: | Answer A is correct; DBA is the role that gives a DBA all the privileges needed to maintain the database. Answer B is incorrect; SYSTEM is a username to which DBA has been granted. Answer C is incorrect; SYSOPER does not have all the needed privileges to maintain the database. Answer D is incorrect; RESOURCE has many privileges but not enough to maintain the database.
A57: | Answer A is correct; because the role was granted to Lynn before she logged in, as soon as she logs in she will be able to access those privileges. Answer B is incorrect; there is no need to log out for her to use the role's privilegesit was enabled when she logged in. Answer C is incorrect; unless otherwise specified, all roles are hers by default. Answer D is incorrect; the point of roles is so that you don't have to directly grant privileges to every user.
A58: | Answer C is correct; REFERENCES is the privilege that allows you to create foreign keys on another user's tables. Answer A is incorrect. There is no CREATE INDEX privilege; it is inferred by the CREATE TABLE privilege but only in the owned schema. Answer B is incorrect; CREATE ANY INDEX won't allow a user to create a foreign key relationship. Answer D is incorrect; there is no CREATE ANY KEY privilege.
A59: | Answer A is correct; AUDIT_TRAIL=DB or AUDIT_TRAIL=OS allows auditing to be enabled in the database. Answer B is incorrect; BEGIN_AUDIT is not a valid initialization parameter. Answer C is incorrect; AUDIT_TRAIL=NONE turns off auditing in your database. Answer D is incorrect; AUDITING is not an initialization parameter.
A60: | Answer A is correct; PASSWORD_LIFE_TIME allows you to set the maximum number of days that can pass before the password is reused. Answer B is incorrect; it is not a valid parameter for password maintenance. Answer C is incorrect; PASSWORD_REUSE_TIME sets the amount of days that must pass before a password can be reused again. Answer D is incorrect; PASSWORD_GRACE_TIME is the period in which you have to change your password after it has expired.


Appendix A. CD Contents and Installation Instructions

The CD features an innovative practice test engine powered by MeasureUp, giving you yet another effective tool to assess your readiness for the exam. The CD also includes a helpful "Need to Know More?" appendix that will break down by chapter extra resources you can visit if some of the topics in this book are still unclear to you.


Multiple Test Modes

MeasureUp practice tests are available in Study, Certification, Custom, Adaptive, Missed Question, and Non-Duplicate question modes.

Study Mode

Tests administered in Study Mode allow you to request the correct answer(s) and explanation for each question during the test. These tests are not timed. You can modify the testing environment during the test by clicking the Options button.

Certification Mode

Tests administered in Certification Mode closely simulate the actual testing environment you will encounter when taking a certification exam. These tests do not allow you to request the answer(s) or explanation for each question until after the exam.

Custom Mode

Custom Mode allows you to specify your preferred testing environment. Use this mode to specify the objectives you want to include in your test, the timer length, and other test properties. You can also modify the testing environment during the test by clicking the Options button.

Adaptive Mode

Tests administered in Adaptive Mode closely simulate the actual testing environment you will encounter when taking an adaptive exam. After answering a question, you are not allowed to go back; you are only allowed to move forward during the exam.

Missed Question Mode

Missed Question Mode allows you to take a test containing only the questions you missed previously.

Non-Duplicate Mode

Non-Duplicate Mode allows you to take a test containing only questions not displayed previously.


Question Types

The practice question types simulate the real exam experience.


Random Questions and Order of Answers

This feature helps you learn the material without memorizing questions and answers. Each time you take a practice test, the questions and answers appear in a different randomized order.


Detailed Explanations of Correct and Incorrect Answers

You'll receive automatic feedback on all correct and incorrect answers. The detailed answer explanations are a superb learning tool in their own right.


Attention to Exam Objectives

MeasureUp practice tests are designed to appropriately balance the questions over each technical area covered by a specific exam.


Installing the CD

The minimum system requirements for the CD-ROM are as listed here:

  • Windows 95, 98, ME, NT4, 2000, or XP

  • 7MB disk space for testing engine

  • An average of 1MB disk space for each test

If you need technical support, please contact MeasureUp at 678-356-5050 or email support@measureup.com. Additionally, you'll find Frequently Asked Questions (FAQs) at www.measureup.com.

To install the CD-ROM, follow these instructions:

1.
Close all applications before beginning this installation.

2.
Insert the CD into your CD-ROM drive. If the setup starts automatically, go to step 6. If the setup does not start automatically, continue with step 3.

3.
From the Start menu, select Run.

4.
Click Browse to locate the MeasureUp CD. In the Browse dialog box, from the Look In drop-down list, select the CD-ROM drive.

5.
In the Browse dialog box, double-click on Setup.exe. In the Run dialog box, click OK to begin the installation.

6.
On the Welcome Screen, click Next.

7.
To agree to the Software License Agreement, click Yes.

8.
On the Choose Destination Location screen, click Next to install the software to C:\Program Files\MeasureUp Practice Tests\Launch.

If you cannot locate MeasureUp Practice Tests through the Start menu, see the section later in this appendix titled "Creating a Shortcut to the MeasureUp Practice Tests."

9.
On the Setup Type screen, select Individual Typical Setup. Click Next to continue.

10.
On the Select Features screen, click the check box next to the test(s) you purchased. After you have checked your test(s), click Next.

11.
On the Enter Text screen, type the password provided in this receipt, and click Next. Follow this step for any additional tests.

12.
On the Select Program Folder screen, verify that the Program Folder is set to MeasureUp Practice Tests, and click Next.

13.
After the installation is complete, verify that Yes, I Want to Restart My Computer Now is selected. If you select No, I Will Restart My Computer Later, you will not be able to use the program until you restart your computer.

14.
Click Finish.

15.
After restarting your computer, choose Start, Programs, MeasureUp Practice Tests, Launch.

16.
On the MeasureUp welcome screen, click Create User Profile.

17.
In the User Profile dialog box, complete the mandatory fields and click Create Profile.

18.
Select the practice test you want to access, and click Start Test.

Creating a Shortcut to the MeasureUp Practice Tests

To create a shortcut to the MeasureUp Practice Tests, follow these steps:

1. | Right-click on your desktop.
2. | From the shortcut menu select New, Shortcut.
3. | Browse to C:\Program Files\MeasureUp Practice Tests and select the MeasureUpCertification.exe or Localware.exe file.
4. | Click OK.
5. | Click Next.
6. | Rename the shortcut MeasureUp.
7. | Click Finish.

After you have completed step 7, use the MeasureUp shortcut on your Desktop to access the MeasureUp products you ordered.


Technical Support

If you encounter problems with the MeasureUp test engine on the CD-ROM, you can contact MeasureUp at 678-356-5050 or email support@measureup.com. Technical support hours are from 8 a.m. to 5 p.m. EST Monday through Friday. Additionally, you'll find Frequently Asked Questions (FAQs) at www.measureup.com.

If you'd like to purchase additional MeasureUp products, telephone 678-356-5050 or 800-649-1MUP (1687), or visit www.measureup.com.


Glossary

Team LiB

Appendix. Glossary

O7_DICTIONARY_ACCESSIBILITY

Intended for use when migrating from Oracle 7 to Oracle 9i, controls restrictions on the SYSTEM privileges. If set to TRUE, full access to objects in the SYS schema is allowed. Default is FALSE meaning that SELECT ANY and EXECUTE ANY are limited to those with appropriately granted privileges.

ACCOUNT LOCK

ALTER USER parameter used to lock a user account.

ACCOUNT UNLOCK

ALTER USER parameter used to unlock a user account.

ADMINISTER_RESOURCE_MANAGER

System privilege granted using the DBMS_RESOURCE_MANAGER_PRIVS package rather than through a typical GRANT statement.

Alert log

Chronological file providing information on errors, log switches, startup, shutdown, and system level changes in the database. A chronological log of messages and errors from the database. Oracle automatically creates a new one when the old one gets deleted.

ALL_ views

Data dictionary views that provide information on all objects to which the currently logged in user has access. This provides not only all the objects owned by the user but also the objects to which the user has been granted access.

ALL_DEF_AUDIT_OPTS

Dictionary view providing audit options for all objects.

ALTER DATABASE

Command used to alter the state of the database.

ALTER INDEX

Command used to alter indexes.

ALTER SYSTEM

Command used to alter the state of the instance.

ALTER TABLE

Command used to alter tables.

ALTER TABLESPACE

Command used to alter the storage parameters of the tablespace.

ALTER USER

Command used to alter users.

Alternate key

Key other than the primary key for the table, also known as subordinate key.

Analyze

Process of gathering statistics on database objects.

ANSI

American National Standards Institute, a privately funded nonprofit organization that coordinates development and approval of entirely voluntary standards in the United States.

ARCHIVELOG

Mode of running the database in which filled redo logs are archived into archive logs before the redo logs can be reused. This mode is used to ensure that complete database recovery can be accomplished.

ARCHIVELOG MODE

Mode of running the database in which filled redo logs are archived into archive logs before the redo logs can be reused. This mode is used to ensure that complete database recovery can be accomplished.

Archiver (ARCH)

Background process started when you start the database in archive log mode.

Archiving

The copying of redo log files to an alternative archival destination. The archival is handled by the ARCH process, which should be turned on to ARCHIVELOG MODE to facilitate online backups of the database.

ASCII

The American Standard Code for Information Interchange (ASCII) is used extensively for data transmission. The character set includes 128 upper- and lowercase letters, numerals, and special characters each encoded by unique 7-bit numbers.

Attribute

The portions of a entity that store the pieces of information about an object. Attributes equate to the columns of a table and typically contains atomic values.

AUDIT

An Oracle command that controls the auditing of objects, statements, or privileges.

Auditing

The process of recording database activity and access to objects as it occurs in the database.

Authentication

Process of determining whether someone or something is what it claims to be.

Authorization

Granting of authority typically based on access rights.

Automatic Segment Space Management

Mode of operation in which Oracle manages free space in segments automatically.

background_dump_dest

Initialization parameter specifying the location, either directory or drive specification, where the debugging trace files from the background processes are written during Oracle operations. Also the location of the alert log file.

Background processes

Oracle processes that maintain the operation of the database. These processes consolidate functions that would otherwise be handled by multiple Oracle programs running for each user process. The background processes asynchronously perform I/O and monitor other Oracle processes to provide increased parallelism for better performance and reliability.

Block

A unit of data transfer between main memory and disk. Many blocks from one section of memory address space form a segment.

Block header

Portion of the block containing control information.

Bootstrap segment

An Oracle data block in the SYSTEM tablespace that contains code used to start a database.

Buffer

A main memory address in which the buffer manager caches currently and recently used data read from disk. Over time, a buffer can hold different blocks. When a new block is needed, the buffer manager can discard an old block and replace it with a new one.

Buffer cache

The portion of the SGA that holds copies of data blocks read from data files. All user processes concurrently connected to the instance share access to the database buffer cache.

Buffer pool

A collection of buffers.

BUFFER_POOL_KEEP

Lets you save objects in the buffer cache by setting aside a portion of the total number of buffers from the allocated number in the DB_BLOCK_BUFFERS parameter as a KEEP buffer pool.

BUFFER_POOL_RECYCLE

Deprecated in favor of the DB_RECYCLE_CACHE_SIZE parameter. BUFFER_POOL_RECYCLE lets you limit the size of objects in the buffer cache by setting aside a portion of the total number of buffers from the allocated value of the DB_BLOCK_BUFFERS parameter as a RECYCLE buffer pool.

Cache

Also known as buffer cache. All buffers and buffer pools.

Cache recovery

The part of instance recovery where Oracle applies all committed and uncommitted changes in the redo log files to the affected data blocks. Also known as the rolling forward phase of instance recovery.

catalog.sql

Script used for creating the data dictionary views.

Character set

An encoding scheme in which each character is represented by a different binary value.

Checkpoint

Occurs when the database writer process writes all modified buffers in the buffer cache to the data files. Checkpoints occur after every log switch and also at intervals specified by initialization parameters.

Cluster segment

Database segment used for storing clusters.

Cluster tables

Optional structure for storing table data. Clusters are groups of one or more tables physically stored together in the same data block because they share common columns and are often used together. Because related rows are physically stored together, disk access time will be significantly improved.

COMPOSITE_LIMIT

In resource manager, a weighted sum, measured in service units, of certain resources.

CONNECT_TIME

Resource manager parameter used to specify the total elapsed time limit for a session, expressed in minutes.

CONTROL_FILE

An Oracle proprietary file that records the physical structure of a database and contains the database name, the names and locations of associated databases and online redo log files, the time stamp of the database creation, the current log sequence number, and checkpoint information. At least one control file is necessary to start an Oracle instance.

core_dump_dest

Primarily a Unix initialization parameter specifying the location where Oracle will write core dump files. May not be supported on all platforms.

CPU_PER_CALL

Resource manager parameter used to specify the CPU time limit for an individual call (for example, a parse, execute, or fetch). Parameter is expressed in hundredths of seconds.

CPU_PER_SESSION

Resource manager parameter used to specify the CPU time limit for a session. Parameter is expressed in hundredths of seconds.

CREATE_BITMAP_AREA_SIZE

Specifies the amount of memory in bytes that will be allocated for bitmap creation. Relevant only for systems using bitmap indexes. Oracle recommends using this parameter only if also using the shared server option. Retained only for backward compatibility.

CREATE BITMAP INDEX

Command used to create bitmap indexes in the database.

CREATE DATABASE

Command issued to create a new database.

CREATE INDEX

Command used to create indexes in the database.

CREATE TABLESPACE

Command used to create a tablespace in the database.

CREATE UNDO TABLESPACE

Command used to create the undo tablespace in the database.

CREATE UNIQUE INDEX

Command used to create unique indexes in the database.

CREATE USER

Command used to create users in the database.

Data block

Smallest logical unit of data storage in an Oracle database. Also known as logical blocks, Oracle blocks, or pages. One data block corresponds to a specific number of bytes of physical database space on disk and is defined by number of kilobytes.

Data dictionary

The core set of tables and views used as a read-only reference about the database in which they appear. The data dictionary contains information such as the logical and physical structure of the database, valid users of the database, information about integrity constraints, how much space has been allocated for any given schema object, and how much of this allocated space is in use. The data dictionary is created when the database is created and is automatically updated whenever the structure of the database is changed.

Data file

A physical operating system file on disk that was created by Oracle, is associated with exactly one tablespace, and contains data structures such as tables and indexes. A data file can only belong to one database.

Data segment

Each nonclustered table has a single dedicated data segment. All the table's data is stored in the extents of its data segment. For a partitioned table, each partition has its own data segment. Each cluster has a single data segment defined for it. The data of every table in the cluster is stored in the cluster's single data segment.

Data warehouse

Typically, a very large database on which decision support systems run.

Database

A collection of data treated as a unit. Stores and provides retrieval capability for related information.

Database buffer cache

Memory structure in the system global area that stores the most recently used blocks of data.

Database Writer (DBWn)

Oracle background process that writes the contents of the buffers to data files. Responsible for writing modified (or dirty) buffers in the database buffer cache to disk.

Date time formats

Specific format of the date and time presented to the user.

DB_BLOCK_BUFFERS

The number of database buffers in the buffer cache. Parameter deprecated in favor of DB_CACHE_SIZE.

DB_BLOCK_SIZE

Default block size in bytes of the database. Can only be specified at databasecreation time, and if it is necessary to change this parameter, the database must be re-created. Defaults to 2KB if left unspecified. Block size of the SYSTEM tablespace.

DB_CACHE_SIZE

Specifies the size of the DEFAULT buffer pool used for those buffers with the primary block size as defined by the DB_BLOCK_SIZE parameter. Size must be at least one granule.

DB_CREATE_FILE_DEST

Sets the default value for where Oracle will create its files if you are using Oracle managed files (OMFs). Can be altered with either the ALTER SYSTEM or ALTER SESSION command. Directory must already exist before you specify this parameter and must have appropriate permissions.

DB_CREATE_ONLINE_LOG_DESTn

Default location for Oracle managed redo log files and control files where n is any integer between 1 and 5 inclusive. At least two should be specified for fault tolerance. Alterable with ALTER SYSTEM or ALTER SESSION. Directory has to already exist before parameter is set and must have appropriate permissions.

DB_DOMAIN

Specifies the logical location of the database within the network. Should be set if database will ever be part of a distributed environment. Oracle recommends that each database in the system have its own unique DB_DOMAIN.

DB_FILES

Specifies the number of data files that can be open in the database. Default value is 200. Maximum value is operating system dependent. Can be changed after database creation, but requires database restart.

DB_KEEP_CACHE_SIZE

Specifies the size of the keep buffer pool in megabytes, kilobytes, or gigabytes and is based on primary blocks. If defined, must be at least one granule. Maximum size is operating system dependent.

DB_NAME

Parameter that must be specified for every instance. Specifies database identifier of up to eight characters and must correspond to the name specified in the CREATE DATABASE statement. Although optional, should be set at the environment level before creating the database and then referenced in that statement.

DB_nK_CACHE_SIZE

specifies the size of the cache for the nK buffers to be used when tablespaces with block sizes other than the default block size are used in the database.

DB_RECYCLE_CACHE_SIZE

Specifies the size of the recycle buffer pool. Sized in kilobytes, megabytes, or gigabytes and based on the default block size for the database. Minimum if set is one granule. Maximum size is operating system dependent.

DB_WRITER_PROCESSES

Specifies the initial number of database writer processes for a system. Defaults to 1 and can take on any number from 1 to 20. Particularly useful for systems that have heavy data modification characteristics.

DBA_ views

DBA_ views provide information on database objects across all schemas. DBA_ views can, and typically do, contain more columns than the corresponding ALL_ or USER_ views.

DBA_AUDIT_EXISTS

Data dictionary view that lists audit trail entries produced by AUDIT NOT EXISTS and AUDIT EXISTS.

DBA_AUDIT_OBJECT

Data dictionary view that holds the audit trail records for statements concerning objects, specifically, table, cluster, view, index, sequence, public database link, public synonym, procedure, trigger, rollback segment, tablespace, role, and user.

DBA_AUDIT_SESSION

Data dictionary view that holds all audit trail records concerning CONNECT and DISCONNECT.

DBA_AUDIT_STATEMENT

Data dictionary view that holds audit trail records concerning grants, revokes, audit, NOAUDIT, and ALTER SYSTEM.

DBA_AUDIT_TRAIL

Data dictionary view containing all audit trail entries.

DBA_COL_PRIVS

Data dictionary view containing all grants on columns in the database.

DBA_DATA_FILES

Data dictionary view containing information about all data files in the database.

DBA_IND_COLUMNS

Provides information on all indexed columns in the database.

DBA_INDEXES

Provides information on all indexes in the database.

DBA_OBJ_AUDIT_OPTS

Data dictionary view containing auditing options for all tables and views.

DBA_OBJECTS

Provides information, including status, on all objects in the database.

DBA_PRIV_AUDIT_OPTS

Data dictionary view that describes current system privileges being audited across the system and those being audited by users.

DBA_ROLE_PRIVS

Data dictionary view that provides information concerning roles that have been granted to users and two other roles.

DBA_ROLES

Data dictionary view that provides information concerning all the roles that exist in the database.

DBA_ROLLBACK_SEGS

Data dictionary view that provides information concerning the description of rollback segments.

DBA_STMT_AUDIT_OPTS

Data dictionary view that describes the current system auditing options enabled both by the system and by the user.

DBA_SYS_PRIVS

Data dictionary view that contains information concerning system privileges granted to users and roles.

DBA_TAB_PRIVS

Data dictionary view that contains information concerning all grants on all objects in the database.

DBA_TABLESPACES

Data dictionary view containing information concerning the description of all tablespaces.

DBA_TEMP_FILES

Data dictionary view containing information concerning all-time files in the database. These are connected to both the default temporary tablespaces and any other temporary tablespaces defined in the database.

DBMS_RESOURCE_MANAGER

Oracle provided package that maintains plans, consumer groups, and plan directives, while also providing the semantics so that you may group together changes to the plan schema.

DBMS_SESSION.SET_ROLE

Package that provides access to SQL ALTER SESSION and SET ROLE statements, as well as other session information, from PL/SQL. You can use this to set preferences and security levels.

DEALLOCATE UNUSED

Clause used to explicitly deallocate unused space at the end of a database object segment and make the space available for other segments in the tablespace.

Decision Support System (DSS)

Database architecture typified by large volumes of data and primarily read-only access. Also often referred to as data warehouses.

DEFAULT PROFILE

Profile assigned to a user if no profile is deliberately assigned to the user.

DEFAULT ROLE

The role or roles enabled at user login time.

Disable

Operation that you can take on an constraint to allow the insertion of data that may or may not pass the constraint test into the database.

DISABLE NOVALIDATE

Constraint state in which the data is not checked and the constraint condition is not necessarily true.

DISABLE VALIDATE

Constraint state that disables the constraint, drops the index on the constraint, and disallows any modification of the constrained columns.

Dispatcher

Background process in a shared server architecture. Responsible for directing request to server process to be handled and the data to be retrieved.

DROP INDEX

Command for removing an index from a table.

Dynamic performance view

Name for the V$ views in the data dictionary that provide dynamic tuning information for the current database state.

Enable

Constraint or role status.

ENABLE NOVALIDATE

Constraint is checked, but it does not have to be true for all rows and allows existing rows to violate the constraint rule, while ensuring that all new or modified rows are valid.

ENABLE VALIDATE

Constraint is checked and is guaranteed to hold for all rows.

EXPIRED

Condition of a password in which the password needs to be changed.

Extent

A specific number of contiguous data blocks allocated for storing a specific type of information (table, index, cluster).

External tables

Operating system flat files accessed using SQL statements as if they were normal tables. Cannot be indexed and cannot have INSERT, UPDATE, or DELETE operations performed.

EXTERNALLY

Authentication option for the CREATE USER statement.

FAILED_LOGIN_ATTEMPTS

Maximum number of failed login attempts for the user. After this number, the account becomes locked.

GLOBAL_NAME

Global database name.

Grant

Means by which you attach privileges or roles to a user or privileges to a role.

High water mark

A special marker used by Oracle to indicate the last block used to hold a table's data.

IDLE_TIME

Maximum amount of time, in minutes, that a user session can be idle without being disconnected.

IFILE

File used to embed one parameter file in another. Several IFILEs can be embedded in a single parameter file, and up to three levels of nesting is possible.

Index

Object that lets you quickly locate particular records based on key column values.

Index organized table segment

Database segment allocated to index organized tables.

Index organized tables

Type of table in which all the data is stored in a B-tree index structure.

Index partition segment

Segment allocated to a partition of a partitioned index.

Index segment

Segment allocated to an index.

Initialization parameter file

File providing static initialization parameters that Oracle reads at instance startup. Naming convention is init<SID>.ora.

Java pool

Location from where Java memory manager allocates most Java statements during runtime operation.

JAVA_POOL_SIZE

Size, in bytes, of Java pool.

Language support

Global support for multiple languages.

Large pool

Memory area of the SGA mainly used when running in Shared Server mode and for buffering sequential file I/O when using recovery manager (RMAN).

LARGE_POOL_SIZE

Specification for the size (in kilobytes or megabytes) of the large pool, used in shared server architecture.

Library cache

Memory area of the SGA where Oracle stores table information, object definitions, and SQL statements.

Linguistic sorting

Alternative method of sorting that takes into account NLS territories.

LOB

Large object Binary.

LOB segment

Database segment used for storing large objects.

Locally managed tablespace

Tablespace managed with bitmap segments internally to the tablespace rather than in the data dictionary.

LOG_BUFFER

Amount of memory in bytes that Oracle uses when buffering redo entries to a redo log file. Larger values typically mean reduced log file I/O. In a busy system, values of 65536 or higher are perfectly reasonable.

LOG_CHECKPOINT_INTERVAL

Frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and when the last block was written to the redo logs. Number specifies operating system blocks, not database blocks.

LOG_CHECKPOINT_TIMEOUT

Frequency in seconds of the amount of time that has passed since the incremental checkpoint and the point where the last write to the redo log files occurred. Also specifies that there will be at most this many seconds that any buffer will remain dirty. Default value is 1,800 seconds.

LOGICAL_READS_PER_CALL

Maximum number of database blocks read per call.

LOGICAL_READS_PER_SESSION

Maximum number of database blocks read per session.

Log Writer (LGWR)

Background process that writes the redo log buffers out to the online redo log files.

Manual Segment Space Management

Space management mode in which the allocation of extents and extent sizing are managed by the DBA.

MAX_DUMP_FILE_SIZE

Maximum size that Oracle will write to a dump file. If the potential dump file would have exceeded this size, Oracle truncates trailing information that is often relevant.

MAXDATAFILES

Maximum number of data files allowed in the database. Alteration of this parameter requires database restart.

MAXEXTENTS

Maximum number of extents in a segment.

MAXLOGFILES

Maximum number of redo log groups.

MAXLOGHISTORY

Permanent database parameter used to specify the maximum number of log switches. This is set in the CREATE DATABASE statement, alterable only with a database re-creation or a control file re-creation.

MAXLOGMEMBERS

Maximum number of log members per redo log file group.

Message support

Multilanguage support for messages, associated with globalization and multilanguage support.

MINEXTENTS

Minimum number of extents allocated to a segment.

Monetary forms

Multilanguage support for different monetary units, associated with globalization and multilanguage support.

National Language Support (NLS)

Support in the database for languages other than the base language chosen for the database.

Nested table segment

Segment used to store nested table's base table.

NLS_CALENDAR

Specifies the calendar system that Oracle will use. Valid values include Arabic Hijra, English Hijra, Gregorian, Japanese Imperial, Persian, Republic of China Official, and Thai Buddha.

NLS_COMP

National Language comparison. Normally when Oracle does comparisons in the WHERE clause and within PL/SQL blocks, the comparisons are binary unless you specify the NLSSORT function. By setting NLS_COMP to ANSI, you indicate to Oracle that all comparisons of this type should use the linguistic sort specified in the NLS_SORT parameter. One caveat is, however, that you must also define an index on the column for which you want Oracle to perform these linguistic sorts.

NLS_DATE_FORMAT

Default format to use when the TO_CHAR or TO_DATE functions are called. The default value is determined by the value to which NLS_TERRITORY is set.

NLS_DATE_LANGUAGE

Language used for spelling out day and month names and abbreviations (a.m., p.m., AD, BC) that gets returned by the TO_DATE and TO_CHAR functions.

NLS_DUAL_CURRENCY

Specifies the dual currency symbol, for example the Euro, that is used for the given territory. The default dual currency symbol is the symbol defined for the territory of your current language environment and is derived from the NLS_TERRITORY setting.

NLS_ISO_CURRENCY

String to use as the international currency symbol for a number element. Ambiguity can be introduced because the dollar sign ($) can refer to US dollars, Canadian dollars, or Australian dollars.

NLS_LANGUAGE

Defines the default language of the database. Language is used for messages, date names and symbols, and for the default sorting mechanism. This parameter helps to determine the values for NLS_DATE_LANGUAGE and NLS_SORT.

NLS_LENGTH_SEMANTICS

Enables you to create CHAR and VARCHAR2 columns that are either byte-based or character-based. Existing columns are not affected.

NLS_NUMERIC_CHARACTERS

Derived from NLS_TERRITORY, this parameter determines the symbol to use as the group and decimal separator.

NLS_SORT

Specifies the collating sequence for ORDER BY queries. Setting this parameter to anything other than binary forces sorts to do full table scans.

NLS_TERRITORY

Name of the territory whose conventions are to be used for date and week numbering. Determines the default date format, default decimal character, group separator, International Standards Organization (ISO), and local currency symbols.

NLS_TIMESTAMP

Default time stamp format to use with the TO_CHAR and TO_TIMESTAMP functions.

NLS_TIMESTAMP_TZ_FORMAT

Default time stamp with time zone format to be used with TO_CHAR and TO_TIMESTAMP functions.

NOARCHIVELOG

Mode in which Oracle does not require the redo logs to be archived before they are overwritten.

Nonstandard block size

Block size of database tables that are not the standard block size as defined by DB_BLOCK_SIZE.

Numeric formats

Multilanguage support for different forms of numeric output (dots versus commas and so forth), associated with globalization and multilanguage support.

Object privileges

Privileges granted on specific objects.

Online redo log files

A mandatory set of two or more files that record all changes made to an Oracle database.

Online Transaction Processing (OLTP) system

Database typified by a large number of inserts, updates, and deletes.

Optimal Flexible Architecture

Recommendations for naming files and folders when installing and implementing an Oracle database.

OPTIMIZER_MODE

Establishes default behavior for choosing optimizer approach for the instance.

ORACLE_BASE

The root of the Oracle directory tree or the uppermost directory under which the Oracle software is installed.

Oracle database

A structured collection of data. The database is the collection of data files and supporting files that allow users to access their data.

Oracle Database Configuration Assistant (DBCA)

Utility for creating, configuring, and removing Oracle databases.

ORACLE_HOME

Corresponds to the environment from which the individual Oracle products run. This environment includes the location of installed product files and is referenced by the PATH variable pointing to the binary files of installed products.

Oracle instance

The set of supporting memory structures and processes associated with a database.

Oracle Server

Oracle installed files along with the database and instance.

ORACLE_SID

Environment variable that holds the Oracle System Id. This corresponds to the database name that you want to attach to.

Oracle Universal Installer

Oracle Java-based utility used to install Oracle software.

OS_AUTHENT_PREFIX

Specifies the prefix that Oracle uses with which to authenticate users attempting to connect to the database using OS Authentication. Oracle concatenates the value of this parameter to the beginning of the given user's operating system account name and password whenever a connection request is attempted. Oracle compares the prefixed username with Oracle usernames in the database.

PASSWORD EXPIRE

CREATE USER clause used to force the new user's password to automatically be expired, forcing that user to have to change the password on first login.

Password file

Stores passwords for users with administrative (SYSDBA and SYSOPER) privileges.

PASSWORD_GRACE_TIME

Resource profile parameter providing the user with the number of days of grace allowed after a password has expired and before the account automatically locks. Users enter the grace period on the first attempt to log in to the database account after the password has expired. During the grace period, a warning message appears each time users try to log in to their account until the grace period expires. Users must change the password within the grace period; if not, the users are prompted for a new password each time an attempt is made to access their account, and access is denied until a new password is supplied.

PASSWORD_LIFE_TIME

Number of consecutive days that a password is allowed to remain unchanged.

PASSWORD_LOCK_TIME

Resource Manager profile parameter reflecting the amount of time that must pass before the user can retry to log in after the account has been temporarily locked due to invalid logins.

PASSWORD_REUSE_MAX

Number of password changes required before the current password can be reused.

PASSWORD_VERIFY_FUNCTION

Function (either Oracle provided or customized by implementation) used to verify passwords to the database.

pctincrease

Percent that you want each additional extent to be grown over the size of the last extent allocated to a segment.

Pending area

Database Resource Manager area to which modifications to a resource plan schema are posted first and validated prior to being submitted to the Oracle database.

PRIVATE_SGA

Name of the function used for password verification for profiles.

Process Monitor (PMON)

Oracle background process responsible for performing process recovery whenever a user process fails and for cleaning up the cache and freeing resources that the failed process was using. PMON is also responsible for checking on dispatcher and server processes and restarting them if they have failed.

Program global area (PGA)

A memory buffer, created when a server process is started, that contains data and control information for the server process.

QUOTA

Amount of space that a given user is permitted in a tablespace or the amount of other resources that a user is permitted via a profile.

REBUILD

Operation to perform on indexes; can be performed online or offline.

Recoverer

Background process responsible for resolving in-doubt transactions across distributed databases.

Recovery manager (RMAN)

A tool that automates and manages the backup and recovery of Oracle databases.

Redo log buffer

Circular buffer in the SGA containing information about changes made to the database.

Redo log groups

Set of one or more (multiplexed) files where Oracle records the changes to the database as they are made. In the event of an instance failure, Oracle reads these files to recover the database. These also track the rollback segments in the database. At least two groups are required, and at least three are suggested.

Redo log members

The individual files within the redo log groups.

Regular tables

Tables in which user data is usually stored with the database.

REMOTE_OS_AUTHENT

Specifies whether remote clients will be authenticated with the value of OS_AUTHENT_PREFIX.

Resource consumer groups

Database Resource Manager construct that allows the database administrator to group user sessions together based on their resource requirements.

Resource directives

Database Resource Manager construct used as a means of assigning consumer groups to particular plans and partitioning resources out among different consumer groups by specifying parameters for each resource allocation method.

RESOURCE_LIMIT

Boolean parameter that determines whether resource limits are enforced in the database with profiles.

RESOURCE_MANAGER_PLAN

Top-level plan to use for an instance. The resource manager will load this top-level plan and all its descendants. If you don't specify this parameter, resource manager is disabled. You can change this setting with the ALTER SYSTEM command. If the plan specified does not exist in the data dictionary, Oracle returns an error.

Resource plans

Database Resource Manager construct used as a means of specifying how the resources are to be distributed among various users in various resource consumer groups.

REVOKE

Removes roles or privileges from users or privileges from roles.

ROLE_ROLE_PRIVS

Data dictionary view providing information about roles that have been granted to roles.

ROLE_SYS_PRIVS

Data dictionary view providing information about system privileges that have been granted to roles.

ROLE_TAB_PRIVS

Data dictionary view providing information about table privileges granted to roles.

Rollback

Activity performed by Oracle to restore data to its state prior to a point where a user started to change it.

Rollback segment

Location where UNDO is managed in manual undo managed database.

Row data

Data retrieved from schema tables.

ROWID

Oracle created and maintained pseudo-column value representing the physical location on disk where the record is stored.

Scalar data types

Simple data types, referencing a single value, cannot be further subdivided into components. In Oracle these are number, char, varchar2, long, and date.

Schema

Equivalent to user. Location under which a user's objects are created.

Schema objects

Database objects (tables, indexes, clusters, and so on) that reside in a user's schema.

Segment

Oracle construct consisting of one or more extents allocated within a tablespace and containing objects.

SESSION

Parameter that specifies the maximum number of sessions that can be created in a system. The default value is derived with the following formula ((1.1 * PROCESSES) +5). This parameter should always be set to an approximation of what you anticipate your maximum number of concurrent users to be plus the number of processes plus a 10% fudge factor.

SESSION_PRIVS

Data dictionary view providing information on privileges that the user currently has set.

SESSION_ROLES

Data dictionary view providing information on roles that the user currently has enabled.

SESSIONS_PER_USER

Number of concurrent multiple sessions allowed per user.

SET_ROLE

Statement used by a user or an application during a session to change the roles currently enabled for the session. Statement can be issued a number of times; however, the user or application must already have been granted the roles that you name in the SET ROLE statement. The maximum number of roles that can be concurrently enabled by any user or application is limited by the initialization parameter MAX_ENABLED_ROLES.

Shared pool

Memory structure containing shared cursors, stored procedures, control structures, and other structures.

SHARED_POOL_SIZE

The size in bytes of the shared pool.

SHUTDOWN

Stop the database and instance.

SHUTDOWN ABORT

Stop immediately. Don't shut down processes. Don't allow users to finish the current transaction. Requires instance recovery upon next open.

SHUTDOWN IMMEDIATE

Immediately log the connected users off, all uncommitted transactions are rolled back, and shut down the database.

SHUTDOWN NORMAL

Stop the database but wait for all connected users to log off and don't stop other users from connecting.

SHUTDOWN TRANSACTIONAL

Stop, but allow connected users to finish current transaction before Oracle automatically logs them off.

SPFILE

The name of the server parameter file (SPFILE) currently in use. Can be defined in a client-side PFILE to indicate the name of the server parameter file to use. When the default server parameter file is used by the server, the value of SPFILE is internally set by the server.

Also, the server parameter file that provides the instance with static as well as dynamic parameters.

SQL_TRACE

Facility allowing an administrator to see what SQL is being run by an application, even if that administrator has only limited access to the program.

STARTUP

Start the instance and optionally open the database.

STARTUP MOUNT

Start up the instance and mount, but don't open, the database. Used for many maintenance tasks.

STARTUP NOMOUNT

Start the instance but don't access any database. Used for creation of new database.

SARTUP OPEN

Start up the instance and open it for access by all users.

STARTUP RESTRICT

Start up the instance and open the database but only allow connections from those with RESTRICTED_SESSION privilege to connect. Used for many maintenance tasks.

Synonym

Alternative name for a database object. Often used to allow a user to access an object belonging to another user without having to prefix the object name with the owner's username.

System global area (SGA)

The memory that Oracle takes when the database is started.

System Monitor (SMON)

Background process created when you start the database. Performs instance recovery, cleans up after dirty shutdowns, and coalesces adjacent free extents into larger free extents.

System privileges

Privileges granted to users to allow users to perform particular systemwide actions or a particular action on a particular type of schema object.

SYSTEM tablespace

Tablespace containing the data dictionary.

Table

Primary object used for storing data in a relational database. Contains rows and columns.

Table partition segment

Segment containing a single partition for a partitioned table.

Table segment

Segment allocated to hold table data.

Templates

A predefined file having a preset format used as a starting point for creating a database through DBCA so that the format does not have to be re-created each time it is used and so that subsequent databases can be created similar to existing.

Temporary segment

Segment allocated to contain only temporary data for sorting.

Temporary tablespace

Tablespace defined for holding only temporary data; used for sorting.

Territory support

Support for local cultural conventions specific to geographical locations including the default local time format, date format, and numeric and monetary conventions that depend on the local territory setting.

TRANSACTIONS

Maximum number of concurrent transactions. Increasing the value increases the size of the SGA and can impact the number of rollback segments allocated. Defaults to a number higher than SESSIONS to account for recursive transactions.

TRUNCATE

Remove all data and lower the high water mark.

UNDO

Data used to provide a read-consistent view of the database and to allow transactions to be rolled back.

UNDO_MANAGEMENT

Specifies which method of undo management should be used for the instance. A setting of AUTO makes the instance start in automatic space management mode. A setting of MANUAL makes the instance start in manual mode in which space is allocated externally as rollback segments.

UNDO_RETENTION

Amount in seconds of undo information that should be maintained in the database for automatic undo management. Current UNDO tablespace needs to have sufficient space to ensure that the value for this parameter is possible.

UNDO SEGMENT

Segment used to hold undo information in automatic undo managed database.

UNDO_SUPPRESS_ERRORS

Enables the suppression of errors encountered by commands executing for external (manual) undo processes. ALTER ROLLBACK SEGMENT under automatic undo management would cause an error if this parameter is not set to trUE. The use of this parameter is intended for systems that want to start using automatic undo while not requiring all programs to be changed initially to eliminate these commands.

UNDO_TABLESPACE

Undo tablespace to be used at instance startup for automatic undo management. If a parameter is omitted, the first available undo tablespace is used. If no undo tablespace is available, the instance starts but uses the SYSTEM rollback segments.

user_dump_dest

Specifies the directory where the server writes the debugging trace files on behalf of the user processes.

User processes

User sessions connected to the database.

USER_ views

Displays all the information from the schema of the current user. No special privileges are required to query these views.

User-defined data types

Oracle-provided capability to define custom data types to meet changing business needs.

V$ views

Dynamic performance views located in the data dictionary.

V$CONTROLFILE

Data dictionary view that provides all the names of all the control files in the database.

V$DATABASE

Data dictionary view that provides access to information about the database that is stored in the control file.

V$DATAFILE

Data dictionary view that contains information about each data file based on the information from the control file.

V$LOG

Data dictionary view that contains information about redo logs from the control file.

V$LOGFILE

Data dictionary view that provides the current status of all redo logs in the database.

V$ROLLNAME

Data dictionary view that lists the names of all rollback segments defined in the database.

V$ROLLSTAT

Data dictionary view that provides statistics about each rollback segment.

V$SESSION

Data dictionary view that lists each session in the instance.

V$TABLESPACES

Data dictionary view that provides information about tablespaces, based on information stored in the control file.

V$TEMPFILE

Data dictionary view that provides information about temp files in the database.

V$TRANSACTION

Data dictionary view that lists all the transactions in the system.

V$UNDOSTAT

Data dictionary view that lists a variety of information about the use of undo space by the database.

VALIDATE STRUCTURE

Validates the structure of the analyzed object. If you use when analyzing a cluster, Oracle automatically validates the structure of all the cluster's tables.

View

Tablelike logical structure that presents a predefined query to the end user.


Appendix C. Need to Know More?

    Chapter 1: Oracle Architectural Components

    Chapter 2: Getting Started with the Oracle Server

    Chapter 3: Creating a Database

    Chapter 4: Managing an Instance

    Chapter 5: Data Dictionary Content and Usage

    Chapter 6: Storage Structure and Relationships

    Chapter 7: Globalization Support

    Chapter 8: Maintaining Control Files

    Chapter 9: Maintaining Redo Log Files

    Chapter 10: Managing Tablespaces and Data Files

    Chapter 11: Managing Undo Data

    Chapter 12: Managing Tables

    Chapter 13: Managing Indexes

    Chapter 14: Maintaining Data Integrity

    Chapter 15: Managing Users

    Chapter 16: Managing Password Security and Resources

    Chapter 17: Managing Privileges

    Chapter 18: Managing Roles


Chapter 1: Oracle Architectural Components

The Oracle 9i Database Concepts Manual, available through http://otn.oracle.com/pls/db92/db92.docindex?remark=homepage is a good source for information on the Oracle architecture.


Chapter 2: Getting Started with the Oracle Server

More information on OEM can be found in Enterprise Manager Administrator's Guide or Enterprise Manager Concepts Guide.

Information on SQL*Plus can be found in SQL*Plus User's Guide and Reference.

Information on password files and orapwd can be found in the Administrator's Guide.

All these references can be found on http://tahiti.oracle.com/.


Chapter 3: Creating a Database

Study the operating system installation and administration guides for your given operating system.


Chapter 4: Managing an Instance

If you want to know more about maintaining the instance, you can find information in the Reference Guide from http://tahiti.oracle.com and in the Administration Guide from the same website.


Chapter 5: Data Dictionary Content and Usage

O'Reilly Press has a good pocket reference book on the Data Dictionary views called, oddly enough, Oracle Data Dictionary Pocket Reference, ISBN 0-596-00517-2.

Also, more information can be found in the Oracle 9i Reference that can be found on http://tahiti.oracle.com.


Chapter 6: Storage Structure and Relationships

To learn more about the Oracle storage structures, you can read the Oracle 9i Database Concepts Manual at http://tahiti.oracle.com.


Chapter 7: Globalization Support

More information on globalization can be found in the Oracle 9i Globalization Support Manual, located through http://tahiti.oracle.com.


Chapter 8: Maintaining Control Files

Oracle 9i DBA 101 by Marlene Theriault, Rachel Carmichael, and James Viscusi from McGraw-Hill Osborne Media, ISBN 0072224746, is an excellent reference in general and can provide further information on the control file if you want additional reading. This is an excellent reference to not only help prepare for your exam but also to have in your library to reference as needed.

Expert Oracle 9i Database Administration by Sam R. Alapati from APress, ISBN 1590590228, also proves to be an excellent source for additional information on control files and many other topics that you will find not only in your quest for the OCP but also in your DBA career.


Chapter 9: Maintaining Redo Log Files

See resource references for Chapter 8, "Maintaining Control Files."


Chapter 10: Managing Tablespaces and Data Files

More information on managing tablespaces and data files can be found on http://tahiti.oracle.com in the Oracle 9i SQL Reference and Oracle 9i Concepts Manuals.


Chapter 11: Managing Undo Data

More information on managing undo data can be found on http://tahiti.oracle.com in the Oracle 9i Parallel Server Concepts and the Oracle 9i Administration Manual.


Chapter 12: Managing Tables

More information on managing tables can be found on http://tahiti.oracle.com in the Oracle 9i Database Concepts Manuals (chapter 12 on Native DataTypes) and in the Oracle 9i SQL Reference found in the same location.


Chapter 13: Managing Indexes

More information on managing indexes can be found on http://tahiti.oracle.com in the Oracle 9i Database Concepts Manuals and in the Oracle 9i SQL Reference found in the same location.


Chapter 14: Maintaining Data Integrity

More information on constraints can be obtained from the Oracle 9i Database Concepts Manual found at http://tahiti.oracle.com.


Chapter 15: Managing Users

More information can be found in the Oracle 9i Database Administrator's Guide concerning user management from http://tahiti.oracle.com.


Chapter 16: Managing Password Security and Resources

More information on managing password security and resources can be found in the Oracle 9i Administrator's Manual on http://tahiti.oracle.com.


Chapter 17: Managing Privileges

A good resource on this subject is Expert Oracle 9i Database Administration by Sam R. Alapati from APress, ISBN 1590590228.


Chapter 18: Managing Roles

More on roles and managing roles can be found in the Oracle 9i Administrator's Guide and the Oracle 9i Concepts Manual on http://tahiti.oracle.com.


Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]


A

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

ACCESS system privileges
accessing
data dictionary 2nd 3rd 4th 5th 6th 7th 8th
account locking 2nd
accounts
expired 2nd
locked 2nd
user accounts
defaults 2nd 3rd 4th 5th 6th 7th
adding
columns (tables) 2nd
data files 2nd 3rd
redo log groups
Administration Functions system privileges
Administration Guide
Administrator's Guide
aging of passwords 2nd 3rd
Alapati, Sam R., Expert Oracle 9i Database Administration 2nd
alert log 2nd 3rd
alertSID.log file 2nd 3rd
allocating
extents 2nd 3rd
ALTER DATABASE command 2nd 3rd 4th 5th
ALTER object privilege
ALTER PROFILE command 2nd
ALTER SESSION command
ALTER SESSION SET CONSTRAINTS command
ALTER SYSTEM command 2nd 3rd
ALTER TABLE commmand 2nd 3rd
ALTER TABLESPACE command 2nd
ALTER USER command
altering
columns (tables) 2nd
database state 2nd
profiles 2nd
tables 2nd 3rd
tablespaces 2nd
undo tablespaces 2nd
altering users 2nd 3rd
answers
practice exam 1 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
practice exam 2 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
application roles
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
ARC (Archiver) processes 2nd
architecture
Optimal Flexible Architecture (OFA) 2nd 3rd 4th 5th 6th
ARCHIVELOG mode 2nd
Archiver (ARC) processes 2nd
archiving
redo log files 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
ARCn (Archiver) background process
arrays
varying arrays 2nd
assessing your readiness for the exam 2nd
assigning
profiles 2nd
users to consumer groups 2nd
ASSM (automatic segment space management) 2nd 3rd
AUDIT command 2nd
AUDIT_TRAIL initialization parameter
auditing
audit trail
errors 2nd
locations 2nd
categories of 2nd
data dictionary 2nd 3rd
data generation
disabling 2nd 3rd
enabling 2nd 3rd
fine-grained auditing 2nd
guidelines 2nd 3rd 4th
options 2nd 3rd 4th 5th
privileges
reviewing audit information 2nd
statement execution 2nd
SYSTEM tablespace 2nd 3rd
uses 2nd
authentication
database authentication 2nd 3rd 4th 5th
external authentication 2nd 3rd 4th 5th 6th 7th
AUTOEXTEND 2nd 3rd
automatic consumer group switching 2nd
automatic segment space management (ASSM) 2nd 3rd
automatic undo management
automation
database startup 2nd


B

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

B-tree indexes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
background processes
Archiver 2nd
ARCn (Archiver)
Checkpoint 2nd 3rd 4th
CKPT
Database Writer 2nd 3rd
defined
Dispatcher 2nd
Job Queue 2nd 3rd
LGWR
Lock Manager Server
Log Writer 2nd
Process Monitor 2nd
Queue Monitor
Recoverer 2nd
System Monitor 2nd
background trace files 2nd
BACKGROUND_DUMP_DEST initialization parameter
backups
control files 2nd 3rd
binary sorting
bitmap indexes 2nd 3rd 4th 5th 6th 7th 8th
block size
default 2nd
block utilitization parameters
INITRANS 2nd
MAXTRANS 2nd
PCTFREE 2nd
PCTUSED 2nd 3rd
blocks
block header
data space
DB_BLOCK_SIZE initialization parameter 2nd 3rd
defined
disk blocks
extents 2nd 3rd 4th
free space 2nd
header 2nd
layout 2nd 3rd 4th 5th
row data
segments
bootstrap segments
cache segments
data segments
defined
index segments
LOBnn segments
rollback segments 2nd
table segments
temporary segments
size 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
space usage 2nd
bootstrap segments 2nd 3rd 4th
buffer cache 2nd


C

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

cache segments
Carmichael, Rachel, Oracle 91 DBA 101
catalog scripts 2nd 3rd 4th 5th
CD
installing 2nd 3rd 4th 5th 6th 7th 8th
MeasureUp practice test engine 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
system requirements 2nd
techical support 2nd
technical support
certification
career goals
educational background 2nd 3rd 4th 5th
expectations
hands-on experience 2nd 3rd 4th 5th
ideal candidate 2nd 3rd 4th
job market 2nd
Oracle training and certification page
character set scanner 2nd 3rd
character sets
converting 2nd 3rd
database 2nd 3rd 4th 5th 6th 7th
encoding schemes 2nd
fixed-width multibyte 2nd
national 2nd 3rd 4th 5th
single-byte 2nd
Unicode 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
varying-width multibyte 2nd 3rd
viewing character set information
Check constraint
checking constraints 2nd 3rd
Checkpoint (CKPT) processes 2nd 3rd 4th
checkpoints
redo log files 2nd 3rd 4th
CKPT (Checkpoint) processes 2nd 3rd 4th
CKPT background process
clearing
redo log files 2nd 3rd 4th
cluster segments 2nd
cluster tables 2nd 3rd
coalescing indexes 2nd
collection data 2nd 3rd 4th 5th
column privileges
columns (tables)
adding 2nd
altering 2nd
dropping 2nd 3rd 4th
inserting 2nd
unused columns 2nd 3rd
command
CREATE PROFILE
commands
ALTER DATABASE 2nd 3rd 4th 5th
ALTER PROFILE 2nd
ALTER SESSION
ALTER SYSTEM 2nd 3rd
ALTER TABLE 2nd 3rd
ALTER TABLESPACE 2nd
ALTER USER
AUDIT 2nd
CREATE CONTROLFILE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
CREATE DATABASE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
CREATE ROLE 2nd 3rd
CREATE SPFILE 2nd
CREATE TABLE 2nd 3rd 4th 5th 6th 7th
CREATE TABLESPACE 2nd 3rd 4th
CREATE USER
DROP PROFILE 2nd
DROP ROLE
DROP TABLE 2nd 3rd
DROP TABLESPACE 2nd 3rd 4th 5th 6th
DROP USER
NOAUDIT 2nd
REVOKE 2nd
SET ROLE 2nd 3rd
SHUTDOWN ABORT 2nd
SHUTDOWN IMMEDIATE 2nd 3rd
SHUTDOWN NORMAL 2nd 3rd
SHUTDOWN TRANSACTIONAL 2nd 3rd
STARTUP 2nd 3rd 4th 5th
STARTUP MOUNT 2nd
STARTUP NOMOUNT 2nd 3rd
STARTUP OPEN 2nd
TRUNCATE
COMPATIBLE initialization parameter
complexity verification of passwords 2nd 3rd 4th
composite partitioning 2nd
COMPOSITE_LIMIT resource limit
CONNECT role
CONNECT_TIME resource limit
connections
instances 2nd 3rd 4th
constraints
advantages
Check
checking 2nd 3rd
data dictionary 2nd
deferred 2nd 3rd
defined 2nd
defining 2nd 3rd
EXCEPTIONS table 2nd 3rd
Foreign key 2nd 3rd 4th 5th 6th 7th 8th 9th
guidelines for using 2nd 3rd
nondeferred
Not NULL
Primary key 2nd 3rd 4th
setting
states 2nd 3rd
table 2nd 3rd 4th 5th 6th 7th 8th 9th
Unique
consumer groups 2nd 3rd 4th 5th 6th 7th 8th
control
defined 2nd
control files
backups 2nd 3rd
contents 2nd 3rd 4th 5th
creating 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
data dictionary 2nd 3rd 4th
defined
dropping 2nd 3rd
duplexed 2nd
information 2nd 3rd 4th
multiplexed 2nd 3rd 4th 5th 6th 7th 8th 9th
nonreusable sections 2nd 3rd
Oracle Managed Files (OMF) 2nd 3rd
parameters 2nd
Recovery Manager (RMAN)
reusable sections 2nd
size
uses 2nd
CONTROL FILES initialization parameter
CONTROL_FILE_RECORD_KEEP_TIME parameter
converting
character sets 2nd 3rd
CPU_PER_CALL resource limit
CPU_PER_SESSION resource limit
CREATE CONTROLFILE command 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
CREATE DATABASE command 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
CREATE PROFILE command
CREATE ROLE command 2nd 3rd
CREATE ROLE system privilege
CREATE SPFILE command 2nd
CREATE TABLE command 2nd 3rd 4th 5th 6th 7th
CREATE TABLESPACE command 2nd 3rd 4th
CREATE USER command
creating
control files 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
data dictionary 2nd 3rd 4th 5th
databases
custom databases
Database Configuration Assistant (DBCA) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
disk space
failures 2nd
manually 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd
operating system environment configuration 2nd 3rd 4th
requirements 2nd
typical databases
datafiles
indexes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
Oracle homes 2nd 3rd
profiles 2nd 3rd 4th 5th 6th
redo log files 2nd
roles 2nd 3rd 4th 5th
SPFILE 2nd
tables 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
tablespaces 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
undo tablespaces
users 2nd 3rd 4th 5th
custom databases


D

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

D (Dispatcher) processes 2nd
data block size
default 2nd
data blocks
block header
characteristics 2nd 3rd
data space
DB_BLOCK_SIZE initialization parameter 2nd 3rd
defined
disk blocks
extents 2nd 3rd 4th
free space 2nd
header 2nd
layout 2nd 3rd 4th 5th
row data
segments
bootstrap segments
cache segments
data segments
defined
index segments
LOBnn segments
rollback segments 2nd
table segments
temporary segments
size 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
space usage 2nd
data dictionary
accessing 2nd 3rd 4th 5th 6th 7th 8th
auditing 2nd 3rd
catalog scripts 2nd 3rd 4th 5th
constraints 2nd
contents 2nd
control files 2nd 3rd 4th
creating 2nd 3rd 4th 5th
globalization support 2nd
indexes 2nd
profiles 2nd
program units
public synonyms 2nd
redo log files 2nd 3rd
roles 2nd 3rd
stored procedures
tables 2nd 3rd 4th
tablespaces 2nd 3rd
undo segments 2nd 3rd 4th
user information 2nd
uses 2nd 3rd 4th
views 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
data dictionary cache 2nd
data files
adding 2nd 3rd
AUTOEXTEND 2nd 3rd
characteristics 2nd
moving 2nd 3rd 4th 5th 6th
data integrity
constraints 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th 38th 39th 40th 41st 42nd 43rd
defined 2nd
triggers 2nd
data segments
data storage
tables
cluster tables 2nd 3rd
index-organized tables 2nd
partitioned tables 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
regular tables 2nd
data types
collection data 2nd 3rd 4th 5th
relationship data types 2nd
scalar data 2nd 3rd 4th 5th 6th 7th 8th 9th
user-defined
database authentication 2nd 3rd 4th 5th
database buffer cache 2nd
database character sets 2nd 3rd 4th 5th 6th 7th
Database Configuration Assistant (DBCA) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
database startup
automation 2nd
OEM interface 2nd
STARTUP command 2nd 3rd 4th 5th
STARTUP MOUNT command 2nd
STARTUP NOMOUNT command 2nd 3rd
STARTUP OPEN command 2nd
Database Writer (DBW) processes 2nd 3rd
databases
backups
control files 2nd
creating
custom databases
Database Configuration Assistant (DBCA) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
disk space
failures 2nd
manually 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd
operating system environment configuration 2nd 3rd 4th
requirements 2nd
typical databases
defined
deleting
down
extents
segments
used extents
file locations 2nd 3rd
instances
connections 2nd 3rd 4th
defined
parameters
archive
required
read-only mode 2nd 3rd 4th
redo log files 2nd 3rd
relationship between structures
relationships 2nd 3rd
restricted mode 2nd 3rd 4th
shutting down 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
states 2nd
tablespaces
defined
system 2nd
temporary
undo 2nd
up
datafiles
creating
defined
DB_BLOCK_BUFFERS initialization parameter
DB_BLOCK_SIZE initialization parameter 2nd 3rd 4th
DB_CREATE_FILE_DEST initialization parameter
DB_CREATE_ONLINE_LOG_DEST initialization parameter
DB_NAME initialization parameter
DBA role
DBA_AUDIT_EXISTS view
DBA_AUDIT_OBJECTS view
DBA_CONSTRAINTS view
DBA_DATA FILES view 2nd
DBA_DATA_FILES view
DBA_EXTENTS view 2nd 3rd 4th
DBA_FREE SPACE view 2nd 3rd 4th
DBA_FREE_SPACE view
DBA_INDEXES view
DBA_LOBS view
DBA_OBJECTS view
DBA_ROLES view
DBA_ROLLBACK_SEGS view
DBA_SEGMENTS view 2nd 3rd 4th
DBA_SYS_PRIVS view
DBA_TABLES view
DBA_TABLESPACE view
DBA_TABLESPACES view
DBA_USERS view
DBCA (Database Configuration Assistant) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
DBCA (Oracle Database Configuration Assistant)
DBW (Database Writer) processes 2nd 3rd
dedicated server architecture 2nd
dedicated server processes
default passwords 2nd 3rd 4th 5th
DEFAULT profile 2nd
default roles 2nd 3rd 4th
default temporary tablespaces 2nd 3rd 4th 5th
defaults
user accounts 2nd 3rd 4th 5th 6th 7th
deferred constraints 2nd 3rd
deferred undo segments 2nd
defining
constraints 2nd 3rd
DELETE CATALOG ROLE
DELETE object privilege
deleting
databases
diagnostic files
alert log 2nd 3rd
background trace files 2nd
user trace files 2nd 3rd
DICT_COLUMNS view
dictionary managed tablespaces 2nd 3rd
DICTIONARY view
directory structures
Optimal Flexible Architecture (OFA) 2nd 3rd
disabled constraints 2nd 3rd
disabling
auditing 2nd
roles 2nd 3rd 4th 5th 6th 7th
disk blocks
Dispatcher (D) processes 2nd
DROP PROFILE command 2nd
DROP ROLE command
DROP TABLE command 2nd 3rd
DROP TABLESPACE command 2nd 3rd 4th 5th 6th
DROP USER command
dropping
columns (tables) 2nd 3rd 4th
control files 2nd 3rd
indexes 2nd
profiles 2nd
redo log groups 2nd 3rd 4th 5th
roles
tables 2nd 3rd
tablespaces 2nd 3rd 4th 5th 6th 7th
undo tablespaces 2nd 3rd
users


E

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

educational background 2nd 3rd 4th 5th
enabled constraints 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
enabling
auditing 2nd
Resource Manager 2nd
roles 2nd 3rd 4th 5th 6th 7th
encoding
passwords
usernames
encoding schemes
defined 2nd
single-byte, 7-bit
single-byte, 8-bit
UTF-16
UTF-8
Enterprise Manager Administrator's Guide
Enterprise Manager Concepts Guide
environment variables
NLS_LANG 2nd 3rd 4th 5th
NLS_SORT
ORA_NLS33 2nd 3rd
environmetn variables
setting 2nd
errors
ORA-1555 snapshot too old error message
UNDO_SUPPRESS_ERRORS 2nd
Event Management System 2nd 3rd
exam preparation
MeasureUp practice test engine 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
EXCEPTIONS table 2nd 3rd
EXECUTE CATALOG ROLE
EXECUTE object privilege
EXP FULL DATABASE role
experience 2nd 3rd 4th 5th
Expert Oracle 9i Database Administration, Sam R. Alapati 2nd
expiration of passwords 2nd 3rd
expired accounts 2nd
explicit parameters
extended ROWIDs 2nd 3rd 4th 5th
extents
allocating 2nd 3rd
characteristics 2nd
defined 2nd 3rd 4th
initial extent
segments
used extents
external authentication 2nd 3rd 4th 5th 6th 7th
external tables 2nd 3rd 4th 5th


F

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

FAILED_LOGIN_ATTEMPTS parameter
files
control files
backups 2nd 3rd
contents 2nd 3rd 4th 5th
creating 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
data dictionary 2nd 3rd 4th
defined 2nd 3rd
dropping 2nd 3rd
duplexed 2nd
information 2nd 3rd 4th
multiplexed 2nd 3rd 4th 5th 6th 7th 8th 9th
nonreusable sections 2nd 3rd
Oracle Managed Files (OMF) 2nd 3rd
parameters 2nd
Recovery Manager (RMAN)
reusable sections 2nd
size
uses 2nd
password files 2nd 3rd 4th 5th
redo log files
archiving 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
defined 2nd 3rd
files (data files)
adding 2nd 3rd
AUTOEXTEND 2nd 3rd
characteristics 2nd
moving 2nd 3rd 4th 5th 6th
fine-grained auditing 2nd
fixed -width multibyte character sets 2nd
forcing
checkpoints
log switches
Foreign key constraint 2nd
Foreign key constraints 2nd 3rd 4th 5th 6th 7th
functions
NLSSORT


G

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

globalization support 2nd 3rd 4th 5th 6th
granting
privileges
object-level 2nd 3rd 4th
system-level 2nd 3rd 4th 5th 6th
roles 2nd 3rd 4th
granules
groups
redo log files 2nd 3rd 4th


H

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

hands-on experience 2nd 3rd 4th 5th
hash partitioning 2nd
history of passwords 2nd
HS_ADMIN_ROLE


I

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

ideal OCA/OCP candidate 2nd 3rd 4th
IDENTIFIED BY clause (roles)
IDLE_TIME resource limit
IFILE initialization parameter
IMP FULL DATABASE role
implicit parameters
INDEX object privilege
index partitions
index segments 2nd
INDEX system privileges
index-organized table (IOT)
index-organized tables 2nd
indexes
B-tree 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
bitmap 2nd 3rd 4th 5th 6th 7th 8th
coalescing 2nd
creating 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
data dictionary 2nd
defined 2nd 3rd
dropping 2nd
logical index classifications 2nd 3rd 4th 5th
nonpartitioned
partitioned
physical index classifications 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
rebuilding 2nd 3rd 4th 5th 6th
storage parameters 2nd 3rd
usage statistics 2nd 3rd
validating 2nd
indexing
linguistic indexing support 2nd
initial extent
initialization parameter files
PFILE 2nd 3rd 4th 5th 6th 7th
SPFILE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
initialization parameters
BACKGROUND_DUMP_DEST
COMPATIBLE
CONTROL FILES
DB_BLOCK_BUFFERS
DB_BLOCK_SIZE 2nd 3rd 4th
DB_CREATE_FILE_DEST
DB_CREATE_ONLINE_LOG_DEST
DB_NAME
IFILE
LOG BUFFER
LOG_ARCHIVE_START initialization parameter 2nd 3rd 4th
MAX_DUMP_FILE_SIZE
PROCESSES
SHARED POOL SIZE
SQL TRACE
TIMED STATISTICS
USER DUMP DEST
INITRANS block utilization parameter 2nd
initSID.ora file 2nd 3rd 4th 5th 6th 7th
INSERT object privilege
inserting
columns (tables) 2nd
installing
CD 2nd 3rd 4th 5th 6th 7th 8th
Instance Manager
instances
connections 2nd 3rd 4th
defined
relationships 2nd 3rd
integrity
constraints 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th 38th 39th 40th 41st 42nd 43rd
defined 2nd
triggers 2nd
IOT (index-organized table)
iSQL*Plus 2nd


J

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

J (Job Queue) processes 2nd 3rd
Java pool 2nd
job market 2nd
Job Queue (J) processes 2nd 3rd
Job Scheduling System 2nd


K

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

Koch, George, Oracle 9i The Complete Reference


L

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

language support 2nd 3rd
language-dependent application behavior 2nd 3rd 4th 5th
Large Objects Binary (LOB) segments 2nd
large pool 2nd
LGWR (Log Writer) processes 2nd
LGWR background process
linguistic indexing support 2nd
linguistic sorting
binary
monolingual 2nd
multilingual 2nd
NLS_SORT environment variable
NLSSORT function
list partitioning 2nd
listing
Oracle homes 2nd 3rd
LMS (Lock Manager Server) processes
LOB (Large Objects Binary) 2nd
LOBnn segments
locally managed tablespaces 2nd 3rd 4th
Lock Manager Server (LMS) processes
locked accounts 2nd
locking
accounts 2nd
LOG BUFFER initialization parameter
log files
redo log files
adding groups
checkpoints 2nd 3rd 4th
clearing 2nd 3rd 4th
configuration
creating 2nd
data dictionary 2nd 3rd
defined
disk location 2nd
dropping groups 2nd 3rd 4th 5th
groups 2nd 3rd 4th
log switches 2nd 3rd
maintaining 2nd
maximum number of groups
multiplexing 2nd 3rd 4th 5th 6th
optimum number of 2nd
purpose of 2nd
recovery
relocating 2nd 3rd
renaming 2nd 3rd
resizing 2nd 3rd 4th
sequence numbers
sizing 2nd 3rd
log switches 2nd 3rd
Log Writer (LGWR) processes 2nd
LOG_ARCHIVE_START initialization parameter 2nd 3rd 4th
logical classification indexes 2nd 3rd 4th 5th
LOGICAL_READS_PER_CALL resource limit
LOGICAL_READS_PER_SESSION resource limit
Loney, Kevin, Oracle 9i The Complete Reference
LONG data type 2nd
LONG RAW data type 2nd


M

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

maintaining
redo log files 2nd
managing
templates 2nd
manual segment space management 2nd
manual undo management mode
defined
support
MAX_DUMP_FILE_SIZE initialization parameter
MAXTRANS block utilization parameter 2nd
MeasureUp
telephone number
MeasureUp practice test engine 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
MeasureUp products
MeasureUp Web site
memory structures
Program Global Area (PGA)
defined 2nd
private SQL area 2nd
SQL work areas 2nd
System Global Area (SGA)
database buffer cache 2nd
defined 2nd
granules
Java pool 2nd
large pool 2nd
redo log buffer 2nd
shared pool 2nd 3rd
modifying
SPFILE 2nd 3rd 4th 5th
monolingual sorting 2nd
moving
data files 2nd 3rd 4th 5th 6th
tables 2nd
multilingual sorting 2nd
multiple Oracle homes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
multiplexing
redo log files 2nd 3rd 4th 5th 6th


N

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

naming
roles 2nd
naming conventions
Oracle Managed File (OMF) System 2nd 3rd 4th 5th
national character sets 2nd 3rd 4th 5th
native language support 2nd 3rd
nested table segments 2nd
nested tables 2nd
NLS_COMP parameter
NLS_LANG environment variable 2nd 3rd 4th 5th
NLS_LANGUAGE parameter 2nd
NLS_SORT environment variable
NLS_TERRITORY parameter 2nd 3rd 4th
NLSSORT function
NLSSORT SQL function
NOARCHIVELOG mode 2nd
NOAUDIT command 2nd
non-SYSTEM undo segments 2nd 3rd
nondeferred constraints
nonpartitioned indexes
nonreusable sections of control files 2nd 3rd
Not NULL constraint
NUMBER(P,S)data type


O

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

O'Reilly Press
object privileges 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
object tables
OEM (Oracle Enterprise Manager) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
OFA (Optimal Flexible Architecture) 2nd 3rd 4th 5th 6th
offline tablespaces 2nd 3rd 4th 5th 6th 7th
OMF (Oracle Managed File) System 2nd 3rd 4th 5th 6th 7th
OMF (Oracle Managed Files)
control files 2nd 3rd
tablespaces 2nd 3rd 4th 5th
OMS (Oracle Management Server) 2nd
OMS Repository 2nd 3rd 4th 5th 6th 7th 8th
online redo log files [See redo log files]
online tablespaces 2nd 3rd 4th
Optimal Flexible Architecture (OFA) 2nd 3rd 4th 5th 6th
ORA-1555 snapshot too old error message
ORA_NLS33 environment variable 2nd 3rd
Oracle 9i Administration Manual
Oracle 9i Administrator's Guide
Oracle 9i Administrator's Manual
Oracle 9i Concepts Manual
Oracle 9i Concepts Manuals
Oracle 9i Database Administrator's Guide
Oracle 9i Database Concepts Manual 2nd 3rd
Oracle 9i Database Concepts Manuals 2nd
Oracle 9i DBA 101
Oracle 9i Globalization Support Manual
Oracle 9i Parallel Server Concepts
Oracle 9i Reference
Oracle 9i SQL Reference 2nd 3rd
Oracle 9i The Complete Reference, Kevin Loney and George Koch
Oracle Data Dictionary Pocket Reference
Oracle Database Configuration Assistant
Oracle Database Configuration Assistant (DBCA)
Oracle Database Resource Manager 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd
Oracle Enterprise Manager (OEM) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
Oracle homes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Oracle Locale Builder 2nd
Oracle Managed File (OMF) System 2nd 3rd 4th 5th 6th 7th
Oracle Managed Files (OMF)
control files 2nd 3rd
tablespaces 2nd 3rd 4th 5th
Oracle Management Server (OMS) 2nd
Oracle processes
Oracle Server
defined
Oracle training and certification page
Oracle Universal Installer (OUI) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
orapwd password utility 2nd 3rd 4th
OS blocks
OUI (Oracle Universal Installer) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st


P

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

parameter files
PFILE 2nd 3rd 4th 5th 6th 7th
SPFILE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
parameters
archive
BACKGROUND_DUMP_DEST
COMPATIBLE
CONTROL FILES
control files 2nd
CONTROL_FILE_RECORD_KEEP_TIME
DB CREATE FILE DEST
DB_BLOCK_BUFFERS
DB_BLOCK_SIZE
DB_CREATE_ONLINE_LOG_DEST
DB_NAME
explicit
FAILED_LOGIN_ATTEMPTS
IFILE
implicit
INITRANS 2nd
LOG BUFFER
MAX_DUMP_FILE_SIZE
MAXTRANS 2nd
NLS_COMP
NLS_LANGUAGE 2nd
NLS_TERRITORY 2nd 3rd 4th
PASSWORD_GRACE_TIME
PASSWORD_LIFE_TIME
PASSWORD_REUSE_MAX
PASSWORD_REUSE_TIME 2nd
PASSWORD_VERIFY_FUNCTION
PCTFREE 2nd
PCTUSED 2nd 3rd
PROCESSES
required
SHARED POOL SIZE
SQL TRACE
TIMED STATISTICS
UNDO MANAGEMENT 2nd 3rd
UNDO TABLESPACE 2nd 3rd 4th 5th
UNDO_RETENTION 2nd 3rd
USER DUMP DEST
partitioned indexes
partitioned tables 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
Password File Utility
password files 2nd 3rd 4th 5th
PASSWORD_GRACE_TIME parameter
PASSWORD_LIFE_TIME parameter
PASSWORD_LOCK_TIME parameter
PASSWORD_REUSE_MAX parameter
PASSWORD_REUSE_TIME parameter 2nd
PASSWORD_VERIFY_FUNCTION parameter
passwords
account locking 2nd
aging 2nd 3rd
complexity verification 2nd 3rd 4th
default passwords 2nd 3rd 4th 5th
encoding
expiration 2nd 3rd
history 2nd
orapwd utility 2nd 3rd 4th
PASSWORD_LOCK_TIME
roles 2nd
setting password limits 2nd 3rd 4th 5th
PCTFREE block utilization parameter 2nd
PCTUSED block utilization parameter 2nd 3rd
pending areas 2nd
performance
Unicode character set 2nd 3rd
persistent parameter files 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
PFILE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
PGA (Program Global Area)
defined 2nd
private SQL area 2nd
SQL work areas 2nd
physical classification indexes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
PMON (Process Monitor) processes 2nd
practice exam 1
answers 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
questions 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th
practice exam 2
answers 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
questions 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th
predefined roles 2nd 3rd 4th 5th 6th
preparing for the exam
MeasureUp practice test engine 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
Primary key constraint
Primary key constraints 2nd 3rd
private SQL area 2nd
PRIVATE_SGA resource limit
privileges
associating with roles
auditing
column privileges
comparison with roles
CREATE TABLE privileges 2nd
defined
granting
object privileges 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
SYSDBA role 2nd 3rd 4th
SYSOPER role 2nd
system privileges 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
turning on/off
Process Monitor (PMON) processes 2nd
processes
background processes
Archiver 2nd
Checkpoint 2nd 3rd 4th
Database Writer 2nd 3rd
defined
Dispatcher 2nd
Job Queue 2nd 3rd
Lock Manager Server
Log Writer 2nd
Process Monitor 2nd
Queue Monitor
Recoverer 2nd
System Monitor 2nd
dedicated server
defined
Oracle
server
shared server
user
PROCESSES initialization parameter
profiles
altering 2nd
assigning 2nd
characteristics 2nd
creating 2nd 3rd 4th 5th 6th
data dictionary 2nd
DEFAULT profile 2nd
defined
dropping 2nd
password limits 2nd 3rd 4th 5th
resource limits 2nd 3rd 4th 5th 6th 7th 8th
uses 2nd
Program Global Area (PGA)
defined 2nd
private SQL area 2nd
SQL work areas 2nd
program units
data dictionary
public synonyms 2nd


Q

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

QMN (Queue Monitor) processes
questions
practice exam 1 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd
practice exam 2 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th
Queue Monitor (QMN) processes
quota for undo segments 2nd 3rd


R

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

range partitioning 2nd 3rd
read consistency (transactions) 2nd 3rd 4th 5th 6th
read-only mode 2nd 3rd 4th
read-only tablespaces 2nd 3rd 4th 5th
rebuilding
indexes 2nd 3rd 4th 5th 6th
RECO (Recoverer) processes 2nd
RECOVER_CATALOG_OWNER role
Recoverer (RECO) processes 2nd
recovering
transactions 2nd
recovery
redo log files
Recovery Manager (RMAN)
redefining
tables 2nd 3rd 4th 5th 6th 7th
redo log buffer 2nd
redo log files
adding groups
archiving 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
checkpoints 2nd 3rd 4th
clearing 2nd 3rd 4th
configuration
creating 2nd
data dictionary 2nd 3rd
defined 2nd 3rd 4th
disk location 2nd
dropping groups 2nd 3rd 4th 5th
groups 2nd 3rd 4th
log switches 2nd 3rd
maintaining 2nd
maximum number of groups
multiplexing 2nd 3rd 4th 5th 6th
optimum number of 2nd
purpose of 2nd
recovery
relocating 2nd 3rd
renaming 2nd 3rd
resizing 2nd 3rd 4th
sequence numbers
sizing 2nd 3rd
Reference Guide
references [See resources]
REFERENCES object privilege
REFs (relationship data types) 2nd
regular tables 2nd
relational tables
relationship data types (REFs) 2nd
relocating
redo log files 2nd 3rd
removing
roles 2nd
renaming
redo log files 2nd 3rd
reorganizing
tables
resizing
redo log files 2nd 3rd 4th
tablespaces 2nd 3rd
resource allocation methods
resource consumer groups 2nd 3rd 4th 5th 6th 7th 8th
resource limits 2nd 3rd 4th 5th 6th 7th 8th
Resource Manager 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd
resource plan directives 2nd
resource plans 2nd 3rd 4th
RESOURCE role
resources
Administration Guide
Administrator's Guide
Enterprise Manager Administrator's Guide
Enterprise Manager Concepts Guide
Expert Oracle 9i Database Administration 2nd
Oracle 9i Administration Manual
Oracle 9i Administrator's Guide
Oracle 9i Administrator's Manual
Oracle 9i Concepts Manual
Oracle 9i Concepts Manuals
Oracle 9i Database Administrator's Guide
Oracle 9i Database Concepts Manual 2nd 3rd
Oracle 9i Database Concepts Manuals 2nd
Oracle 9i DBA 101, Marlene Theriault, Rachel Carmichael, and James Viscusi
Oracle 9i Globalization Support Manual
Oracle 9i Parallel Server Concepts
Oracle 9i Reference
Oracle 9i SQL Reference 2nd 3rd
Oracle Data Dictionary Pocket Reference
Reference Guide
SQL*Plus User's Guide and Reference
response files
restricted mode 2nd 3rd 4th
restricted ROWIDs 2nd 3rd
reusable sections of control files 2nd
REVOKE command 2nd
RMAN (Recovery Manager)
roles
application roles
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
characteristics 2nd
CONNECT
creating 2nd 3rd 4th 5th
data dictionary 2nd 3rd
DBA
default roles 2nd 3rd 4th
defined
DELETE CATALOG ROLE
disabling 2nd 3rd 4th 5th 6th 7th
dropping
enabling 2nd 3rd 4th 5th 6th 7th
EXECUTE CATALOG ROLE
EXP FULL DATABASE
granting 2nd 3rd 4th
HS_ADMIN_ROLE
identification
IMP FULL DATABASE
maximum number of enabled roles
naming 2nd
passwords 2nd
predefined roles 2nd 3rd 4th 5th 6th
privileges
associations
column privileges
comparison
granting
object privileges 2nd
system privileges 2nd
turning on/off
RECOVER_CATALOG_OWNER
removing 2nd
RESOURCE
SELECT_CATALOG_ROLE
SNMPAGENT
SYSDBA
privileges 2nd 3rd 4th
SYSOPER
privileges 2nd
rollback segments 3rd [See manual undo management mode]
rollbacks [See undos]
ROWID data type 2nd 3rd
ROWIDs 2nd 3rd 4th 5th 6th 7th
rows (tables)
structure 2nd 3rd


S

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

scalar data 2nd 3rd 4th 5th 6th 7th 8th 9th
Schema Manager
schema objects
defined
schemas
defined
SCN (system change number)
scripts
catalog scripts 2nd 3rd 4th 5th
Security Manager
segments
automatic segment space management (ASSM) 2nd 3rd
bootstrap 2nd 3rd
bootstrap segments
cache segments
characteristics 2nd
clusters 2nd
data segments
defined 2nd
extents
index partitions
index segments
index-organized table
indexes
Large Objects Binary (LOB) 2nd
LOBnn segments
manual segment space management 2nd
nested tables 2nd
rollback segments 2nd
table partitions 2nd
table segments
tables 2nd
temporary
temporary segments
undo
SELECT object privilege
SELECT_CATALOG_ROLE
self-assessment
determining your readiness for the exam 2nd
educational background 2nd 3rd 4th 5th
expectations 2nd
hands-on experience 2nd 3rd 4th 5th
server parameter file (SPFILE) 2nd
server processes
session-specific temporary tables 2nd 3rd
sessions
defined 2nd 3rd
SESSIONS_PER_USER resource limit
SET CONSTRAINTS statement 2nd
SET ROLE command 2nd 3rd
setting
constraints
environment variables 2nd
SGA (System Global Area)
database buffer cache 2nd
defined 2nd
granules
Java pool 2nd
large pool 2nd
redo log buffer 2nd
shared pool 2nd 3rd
Shared Global Area
shared PL/SQL area 2nd
shared pool 2nd 3rd
SHARED POOL SIZE initialization parameter
shared server architecture 2nd
shared server processes
shared SQL area 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
shortcut
MeasureUp practice tests 2nd 3rd
SHUTDOWN ABORT command 2nd
SHUTDOWN IMMEDIATE command 2nd 3rd
SHUTDOWN NORMAL command 2nd 3rd
SHUTDOWN TRANSACTIONAL command 2nd 3rd
shutting down databases 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
single-byte character sets 2nd
sizing
redo log files 2nd 3rd
undo tablespaces 2nd 3rd 4th 5th
SMON (System Monitor) processes 2nd
SNMPAGENT role
sorting
binary
monolingual 2nd
multilingual 2nd
NLS_SORT environment variable
NLSSORT function
SPFILE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
SPFILE (server parameter file) 2nd
spfileSID.ora file 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
SQL functions
NLS parameters 2nd 3rd 4th 5th
NLSSORT
SQL TRACE initialization parameter
SQL work areas 2nd
SQL*Loader 2nd 3rd
SQL*Plus User's Guide and Reference
SQL*Plus utility
SQL*Plus utlity 2nd 3rd
SQL*Plus Worksheet
starting
Oracle Universal Installer (OUI)
starting databases
automation 2nd
OEM interface 2nd
STARTUP command 2nd 3rd 4th 5th
STARTUP MOUNT command 2nd
STARTUP NOMOUNT command 2nd 3rd
STARTUP OPEN command 2nd
STARTUP command 2nd 3rd 4th 5th
STARTUP MOUNT command 2nd
STARTUP NOMOUNT command 2nd 3rd
STARTUP OPEN command 2nd
statement execution
auditing 2nd
static parameter files 2nd 3rd 4th 5th 6th 7th
statistics on index usage 2nd 3rd
statuses of tablespaces
offline 2nd 3rd 4th 5th 6th 7th
online 2nd 3rd 4th
read-only 2nd 3rd 4th 5th
Storage Manager
storage parameters
indexes 2nd 3rd
stored procedures
data dictionary
storing data
tables
cluster tables 2nd 3rd
index-organized tables 2nd
partitioned tables 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
regular tables 2nd
switching
undo tablespaces 2nd
synonyms
defined
SYSDBA role
privileges 2nd 3rd 4th
SYSOPER role
privileges 2nd
system change number (SCN)
System Global Area (SGA)
database buffer cache 2nd
defined 2nd
granules
Java pool 2nd
large pool 2nd
redo log buffer 2nd
shared pool 2nd 3rd
System Monitor (SMON) processes 2nd
system privileges 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
system tablespace 2nd
SYSTEM tablespace
auditing 2nd 3rd
defined
SYSTEM undo segments


T

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

table constraints 2nd 3rd
table partition segments 2nd
table segments 2nd 3rd
TABLE system privileges
tables
allocating extents 2nd 3rd
altering 2nd 3rd
cluster tables 2nd 3rd
columns
adding 2nd
altering 2nd
dropping 2nd 3rd 4th
inserting 2nd
unused columns 2nd 3rd
creating 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
data dictionary 2nd 3rd 4th
data types
collection data 2nd 3rd 4th 5th
relationship data types (REFs) 2nd
scalar data 2nd 3rd 4th 5th 6th 7th 8th 9th
user-defined
defined
dropping 2nd 3rd
extents 2nd 3rd
external tables 2nd 3rd 4th 5th
index-organized tables 2nd
moving 2nd
nested tables 2nd
object tables
partitioned tables 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
privileges 2nd
redefining 2nd 3rd 4th 5th 6th 7th
regular tables 2nd
relational tables
reorganizing
rows
structure 2nd 3rd
temporary tables 2nd 3rd 4th 5th
truncating 2nd 3rd
TABLESPACE system privileges
tablespaces
altering 2nd
characteristics 2nd 3rd
creating 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
data dictionary 2nd 3rd
data files
adding 2nd 3rd
AUTOEXTEND 2nd 3rd
moving 2nd 3rd 4th 5th 6th
default temporary tablespaces 2nd 3rd 4th 5th
defined
dictionary managed 2nd 3rd
dropping 2nd 3rd 4th 5th 6th 7th
locally managed 2nd 3rd 4th
Oracle Managed Files (OMF) 2nd 3rd 4th 5th
resizing 2nd 3rd
statuses
offline 2nd 3rd 4th 5th 6th 7th
online 2nd 3rd 4th
read-only 2nd 3rd 4th 5th
storage settings 2nd
system 2nd
SYSTEM tablespace
auditing 2nd 3rd
defined
temporary
temporary tablespaces 2nd 3rd 4th 5th 6th 7th
undo 2nd
undo tablespaces 2nd
altering 2nd
creating
dropping 2nd 3rd
ORA-1555 snapshot too old error message
sizing 2nd 3rd 4th 5th
switching 2nd
technical support for CD 2nd 3rd
templates
managing 2nd
temporary segments 2nd
temporary tables 2nd 3rd 4th 5th
temporary tablespace
temporary tablespaces 2nd 3rd 4th 5th 6th 7th
test preparation [See exam preparation]
Theriault, Marlene, Oracle 91 DBA 101
tiiksLOracle Database Configuration Assistant (DBCA)
TIMED STATISTICS initialization parameter
TIMESTAMP data type 2nd
tools
character set scanner 2nd 3rd
Oracle Database Configuration Assistant
Oracle Enterprise Manager (OEM) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
Oracle Locale Builder 2nd
Oracle Universal Installer (OUI) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
orapwd 2nd 3rd 4th
Password File Utility
SQL*Plus utility
SQL*Plus utlity 2nd 3rd
transaction-specific temporary tables
transactions
manual undo management mode
defined
support
undo segments
data dictionary 2nd 3rd 4th
deferred 2nd
defined 2nd
headers
internal transaction table
non-SYSTEM 2nd 3rd
quota 2nd 3rd
read consistency 2nd 3rd 4th 5th 6th
SYSTEM
transaction recovery 2nd
transaction rollback
triggers
defined 2nd
TRUNCATE command
truncating
tables 2nd 3rd
turning on/off
privileges
types of data [See data types]
typical databases


U

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

UNDO MANAGEMENT parameter 2nd 3rd
undo segements
deferred 2nd
defined 2nd
headers
internal transaction table
non-SYSTEM 2nd 3rd
read consistency 2nd 3rd 4th 5th 6th
SYSTEM
transaction recovery 2nd
transaction rollback
undo segments
data dictionary 2nd 3rd 4th
quota 2nd 3rd
undo tablespace 2nd
UNDO TABLESPACE parameter 2nd 3rd 4th 5th
undo tablespaces 2nd
altering 2nd
creating
dropping 2nd 3rd
ORA-1555 snapshot too old error message
sizing 2nd 3rd 4th 5th
switching 2nd
UNDO_RETENTION parameter 2nd 3rd
UNDO_SUPPRESS_ERRORS 2nd
Unicode character set 2nd 3rd 4th 5th 6th 7th 8th
Unicode character sets 2nd 3rd 4th
Unique constraint
UPDATE object privilege
usage statistics for indexes 2nd 3rd
used extents
user accounts
defaults 2nd 3rd 4th 5th 6th 7th
USER DUMP DEST initialization parameter
user processes
user trace files 2nd 3rd
user-defined data types
usernames
encoding
users
altering 2nd 3rd
assigning profiles to users 2nd
authentication
database authentication 2nd 3rd 4th 5th
external authentication 2nd 3rd 4th 5th 6th 7th
consumer groups 2nd 3rd 4th 5th 6th 7th 8th
creating 2nd 3rd 4th 5th
data dictionary 2nd
dropping
Users system privileges
utilities
character set scanner 2nd 3rd
Oracle Locale Builder 2nd
Oracle Universal Installer (OUI) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
orapwd 2nd 3rd 4th
Password File Utility
SQL*Plus 2nd 3rd 4th


V

Team LiB

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

V$ views
V$NLS_PARAMETERS
V$NLS_VALID_VALUES
validating
indexes 2nd
varying arrays 2nd
varying-width multibyte character sets 2nd 3rd
views
data dictionary 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
DBA_DATA FILES 2nd
DBA_EXTENTS 2nd 3rd
DBA_FREE SPACE 2nd 3rd 4th
DBA_SEGMENTS 2nd 3rd
DBA_TABLESPACES
defined 2nd
Viscusi, James, Oracle 91 DBA 101


W

Team LiB
Previous Section

Index

[A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

Web site resources
Administration Guide
Administrator's Guide
Enterprise Manager Administrator's Guide
Enterprise Manager Concepts Guide
Oracle 9i Administration Manual
Oracle 9i Administrator's Guide
Oracle 9i Administrator's Manual
Oracle 9i Concepts Manual
Oracle 9i Concepts Manuals
Oracle 9i Database Administrator's Guide
Oracle 9i Database Concepts Manual 2nd 3rd
Oracle 9i Database Concepts Manuals 2nd
Oracle 9i Globalization Support Manual
Oracle 9i Parallel Server Concepts
Oracle 9i Reference
Oracle 9i SQL Reference 2nd 3rd
Reference Guide
SQL*Plus User's Guide and Reference
Web sites
MeasureUp

Team LiB
Previous Section